Cloudflare breaks all browsers except Firefox

I migrated a very old static site from a web server to an S3 bucket. The site had been working fine with Cloudflare until I made this change. It is very old and basic HTML.

The S3 Bucket URL is:

The raw site with this long URL is viewable on any modern browser Mac or PC.

I configured Cloudflare in a very basic way (CNAME to S3, SSL from Cloudflare, etc.) and

Only works on Firefox for some reason.

Firefox can display the site fine (Mac or PC) yet no other browser can view it. Edge, Chrome, Opera, Safari, Mac/PC/iOS makes no difference. I just get garbage per the screen shot.


your Content-Encoding header’s syntax isn’t valid.

These lines should have a protocol

<link rel="stylesheet" type="text/css" media="all" href="rw_common/themes/tigerpop/consolidated.css" />
<script type="text/javascript" src="rw_common/themes/tigerpop/javascript.js"></script>
1 Like

How come it works off the raw HTML (when bypassing Cloudflare). Is it Cloudflare that gets confused by the invalid syntax? If so, why does Firefox still work through Cloudflare?

Cloudflare modify lots of thing. May be some of minifying html/js/css is breaking your script further.

But then how come the site worked on the old web server. It seems like an interaction between S3 and Cloudflare that didn’t exist prior when it was a normal web server and Cloudflare.

1 Like

may be u r using difference apache version…different php version on old server.

Problem Solved - I manually uploaded the individual files to the S3 bucket via the Amazon web front and this seems to have fixed the problem. I made no changes to the HTML or any other config. The only difference was manually uploading the files. Have no idea why this makes a difference for Cloudflare or why Firefox is immune to whatever bug is causing this.

I did some more digging and definitively found the problem. The software I was using to upload the files was somehow causing S3 to set a metadata key (Content-Encoding) with no value.


Removing this key solved the problem. This needs to be done on all the files that have this problem.

Why this breaks things? Someone else can figure that out.

Incidentally, this is where you can find it from the S3 front-end.

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