Randomly switching header on static site

On our static site we have set 2 Content Security Policy headers, one for the rest of the site and one for this particular page. On that page we are seeing what appears to be random switching between the 2 headers when the page is refreshed or loaded causing the app on the page to be disabled.

The attached gifs illustrate the problem: Sometimes the page loads fine, refresh again and sometimes it throws an error about Content Security Policy which is being used on the other pages.

Load page and it breaks:

Load same page a second later and it’s fine

And a reload later of the same page a second later and it breaks again

URL is Higher Rate Relief Claim | Swiftaid – Gift Aid made easy if anyone wants to test.

Just to reiterate that in between page loads there have been no external changes that could cause this: I am not clearing cache and not rebuilding the server. It’s all happening within same window/session a few seconds apart.

This is a big problem for us because the app on the page is non-functional when the CSP throws the error, we’ve set up an automated test to alarm when it changes and it seems completely intermittent.

Does anyone have any idea what is going on or how to fix it? Some overzealous caching by Cloudflare perhaps? Any ideas or similar experiences would be greatly appreciated.

Hey Mike,
I took a look at the headers you define on your service and those that returned when a request is made - each time the request fails it relates to the jsd-widget.atlassian.com - is that something you’re loading? A ‘clean’ load shows the content-security-policy as you exactly have it set but I’m suspicious that something outside of Render is messing with it here.

John B

Hi John

Yes we are loading the Jira Service widget on that page via a script tag. The error is highlighting jsd-widget (Jira Service widget) as that’s not cleared by the stricter (longer) version of content-security-policy, so that’s why it relates to the failed request.

The header is swapping back and forth randomly, I think it might be a server caching issue and I wonder if there’s any correlation between failed requests and cloudflare headers…

Here’s another gif that shows the different content-security-policy headers being loaded after a few seconds reload on the same page just to re-illustrate, but I’m still clueless.


Or could it be something going on with the way we’ve set the header for that particular page?

Oh, are you saying that the longer policy was one that you previously yourself added and it’s not the policy that you presently have set being fudged by something in the request?

John B

No, what I’m saying is that the header is changing between requests.

To clarify, I’ve added a vanilla project on a public repo here GitHub - altescape/render-header-test: Testing stability of render.com header settings which is hosted on Render header test

There are 2 versions of the same header, one version is set for all pages, the other version is set for the page /header-test. Randomly though when requesting Render header test the header will change between versions. See new gif to illustrate:


Hopefully this makes it clearer. The same header is switching values between header-foo-1 and header-foo-2

The headers are set in the render.yaml. The issue is either with the way the header is set or caching I think.

Thanks for providing a perfect repo case, I’ll get this escalated and investigated.


John B

As a further test, could you try putting the explicit path rule first and the wildcards after it and see if that improves thing?

John B

ignore that, I’m thinking about rewrite rules which have ordering, not headers.

John B

What’s interesting is that I can’t duplicate it with curl, I get a consistent header-foo-2 returned each time:

$ curl -Is https://render-header-test.onrender.com/header-test | grep x-foox-foo: header-foo-2

John B

and the same in Chrome:

John B

This is the odd thing, mostly it will work and then intermittently it will break. Sometimes removing trailing slash will break. I don’t get consistent behaviour to be able to tell you how.

I’ve done some further testing in Chrome and Curl and I think it’s something to do with the way that we’ve set the header with the wildcard.

The problem is trailing slashes, I think, to get around people hitting our URL with and without trailing slashes we tried using the following headers settings:

Header setting scenario 1

Request path Header name Header value
/* X-Foo header-foo-1
/header-test X-Foo header-foo-2
/header-test/ X-Foo header-foo-2

If URL requested includes a trailing slash e.g. /header-test/ and the headers are set as above then we were seeing the following happen:

Request path Returned header value
/header-test header-foo-2
/header-test/ header-foo-1

See screenshot:

Which is unexpected…to get around this we tried scenario 2:

Header setting scenario 2

Request path Header name Header value
/* X-Foo header-foo-1
/header-test X-Foo header-foo-2
/header-test* X-Foo header-foo-2

If URL requested includes a trailing slash e.g. /header-test/ and the above headers are set then we were seeing the following scenario happening:

Request path Returned header value
/header-test header-foo-2 but sometimes header-foo-1 would appear instead
/header-test/ header-foo-2 but sometimes header-foo-1 would appear instead

Header setting scenario 3

The following setting seems to work as expected:

Request path Header name Header value
/* X-Foo header-foo-1
/header-test X-Foo header-foo-2
/header-test/* X-Foo header-foo-2

All requests to /header-test or /header-test/ returns the correct value of header-foo-2

So it could be that we were tripping up on a misconfiguration and the system was doing something weird when it encountered the config…possibly.

Nice debugging @Mike_Watts. Thanks for your persistence with this. Is there anything we can help you investigate further?

Hi David,

No, I don’t think there is anything further that needs to be said on the subject.

I think for future reference it would be a good idea to document what can and can’t be done when setting headers as the behaviour is unexpected in scenario 1 and 2 stated above. We spent an inordinate amount of time trying to figure out what was wrong in the randomness we were seeing not knowing whether it was app changes, cache issues or something else.

Maybe adding a config for either removing or appending trailing slashes could also help with this.

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