Caching issue - "hello" in the respone

Has anybody been faced with the issue where compiled JS and CSS files could be returned from the Cloudflare cache with the “hello” text in the response instead of actual js/css?

This is a location-specific issue: California/San Francisco.

Very weird.

So if you use a VPN to any other location you get the correct result/output?
If so, please make sure your are served a fresh copy of the file, not a cached one.

Also: please provide us with the URL to this specific file so we can run our tests from our end.

1 Like

If you’re on Netlify, open a ticket with Support. And let Netlify know as well.

2 Likes

Thanks @M4rt1n for the quick reply, very weird indeed, we are having this issue in our admin dashboard, everytime someone reports the issue, we are manually purging the cache in Cloudflare, and that fixes it temporarily, we also had to enable “Development Mode” in Cloudfare, but this issue is creating a lot of trouble for us, since many of our workers depend on this system all the time, our workers are in San Francisco, I can only replicate it if I use a VPN, it’s not happening right now, since I just purged the cache, but it will happen again in one hour or so.

How can I send the URL of one of the files that are failing, it won’t let me paste it here.

Just format it as code.

Also, please read @sdayman’s response and tell us if you are using Netflify.

It’s happening right now, i disabled development mode so you could check:

https://admin.gantri.com/static/js/main.5bf61dc9.js

Thanks @sdayman @M4rt1n yes, we are using Netlify, we’ll contact their support team as well.

I can confirm, I do get served “hello” when accessing this URL from LAX.
As mentioned above, please open a support ticket and post here the #id of it.

Since Cloudflare is a reverse proxy, it will just cache what it gets served from the origin. Weird, that the issue is gone in development mode. But this also can be a temporary issue on the origin side, which then just will be cached and therefore gets noticed.

Can’t say much without speculating.

From ZAG or VIE, I can see the content of that particular script.

fl=114f240
h=admin.gantri.com
ip=myip
ts=1662672501.229
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
colo=VIE
sliver=none
http=http/2
loc=HR
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
kex=X25519

Which VPN you’ve used?

Thanks @M4rt1n we created a ticket with Netlify, this is the Id: 108187

Thank you for your help

Hey, thanks for testing, I purged the cache and re-enabled development mode, that fixes temporarily for us, not sure if that’s the reason why you didn’t get it, I’m using express VPN.

It seems like more people are getting that issues as well. https://answers.netlify.com/t/javascript-and-css-assets-sporadically-returning-text-plain-with-a-body-hello/75137

Hey guys, the Netlify support team believes that this error is actually on Cloudflare’s side, in that URL you can see what their response is.

What I read was:

we do not provide tech support for people who proxy to our service from Cloudflare nor anywhere else, at least not below the enterprise account level.

Maybe time to switch to Cloudflare Pages.

1 Like

Netlify have a support guide on why not to put Cloudflare in front of Netlify

These are very cheap excuses and arguments. Most of these don’t make sense at all, some make sense, but are not important for those users who want to proxy through Cloudflare.

Here the argument of NF and my comment:

  • atomic deploys and rollbacks (Cloudflare will cache assets for most customers, for 5 minutes longer (at best!) than our default settings specify). This would lead to changes you make not showing up immediately on the web.

Yes Atomos Deploy and Rollbacks could be a problem, but providing an API with Cache-Clear permission would entirely solve that problem. So someone clearly does not want to support Cloudflare for some reasons.

  • Proxying to us completely breaks some of our features and services, like Analytics and Split Testing.

Yes, Analytics can be influenced, but NF basically would be able to restore all necessary data (like origin IP) if they would like to do so.

  • will likely provide slower service than using our CDN directly (measured by a customer over a few months, using google webmaster tools)

Can’t argue here, some things are faster here, some here. But if someone proxies through Cloudflare their main point is to save costs. And NF just serves low traffic sites for free.

  • our Support team do not have any visibility into what happens to network requests that go through Cloudflare’s CDN (which always happens if you use the orange cloud), so we cannot easily advise you on problems in your configuration or help you debug connection trouble.

That is true.

  • Country-based redirects may not work reliably; we’ll look up Cloudflare’s IP, not your visitor’s, to decide which country the request comes from.

Restoring origin IPs solves this.

  • and occasionally, catastrophic failures have been observed using this setup, and something goes wrong in the proxying. In these cases the only effective, quick fix has been disabling Cloudflare’s proxying as shown below.

This may work, but does not prove at all that the problem originated from Cloudflare.

Just think about it: if NF serves a wrong file, Cloudflare will cache it. And it will be visible for a long time. But here Cloudflare would expose a bug/error that originates from NF - not the other way around.

I am not saying that NF is the problem here, maybe they are, maybe it’s Cloudflares fault. But it is very poor to say: we take our time to read this, but we just don’t look into this, even knowing there is a chance that the problem roots from us.
That is very weird and user unfriendly.

@andrew84 what @sdayman ment here, was:

open a support ticket at Cloudflare, and let NF know as well. AFAIK you have not opened a Support ticket at Cloudflare, but just a NF (#108187). Please create one at Cloudflare as well and describe what you are experiencing. Please also keep in mind that there also is a chance that the problem is rooting from you (your configuration or any worker script function etc).

I personally can’t look into this, as I do not work for Cloudflare, I am just a part of this community, but support very likely will have a look at it. Please post the Cloudflare ticket #id here, as soon as you get one.

I think it is very poor, from a service provider to not even look into something and may hint, that they do not find anything out of the oridinary on their side.

Anyway, depending on what you do and what type of website you run, consider switching to Cloudflare Pages, if it offers all functionality you need :slight_smile: If something does not work, you know here people look into it.

4 Likes

I only shared the information that I know exists.

Netlify has confirmed the issue is from their end here: https://answers.netlify.com/t/javascript-and-css-assets-sporadically-returning-text-plain-with-a-body-hello/75137/14

Thank you for the heads-up!

And that is why Cloudflare does have a place to support ALL users/customers. To detect such issues before an enterprise customer does notice. That also is a good reason to at least look into every issue, even if people are using a combination of services/technology they don’t like.

I also can’t get around the fact that their explanation still sounds like it was Cloudflare’s fault, or at least points to Cloudflare a little.

[…] Unfortunately, in a subset of CDN locations, for customers on our regular network (not HP Edge) that have a proxy in front of Netlify, those test responses were routed through their proxy. That meant that these test responses were cached there and served instead of the corresponding asset. […]

Having a reverseProxy CDN in front of it does not change anything in this case. As the proxy just sees, what every other request would have seen as well. The only difference is, that this will be cached.
For me this seems like they try to defend their point of not having a reverseProxy CDN in front of them, even though it was not the problem after all.