Static website uploaded to pages renders as text only

Developers Cloudflare Pages
1

I’m new to Cloudflare so this is probably something obvious that I’ve done wrong…

Currently I host a old static website (circa 2004) at dreamhost. It works fine over there. That URL is tinkerville.cutthatout.com

I’d like to move it over to Cloudflare pages so I can drop the dreamhost account. I created a new project and used “direct upload” to send all my pages up to Cloudflare. 774 Files uploaded successfully.

I went with direct upload because this isn’t already set up in a git and since I don’t ever plan to change or update the code, this seemed like the least complicated approach.

Everything looks like it worked, but when I visit the site tinkerville.pages.dev, the index.html page is rendered as text. If I enter the URL for an image my browser prompts me to select a local location to save the file.

I’m using Firefox on Windows primarily but I have verified the problem occurs in Edge on Windows and in Brave on Android as well.

I’m sure I’ve just failed to configure something properly, but I’m at a loss where to start since even basic image serving doesn’t work.

Any guidance would be appreciated.

2

I solved this issue by deleting the project and making a new one pulling from github. All of the files are identical to what I direct uploaded, but for some reason this worked.

I can only conclude the direct upload feature is broken.

3

Curiously, I have observed the same issue in the past, and found the same solution, as @dan2.

As a test, I deployed a three page test site via direct upload to https://wrkr-direct-upload-test.pages.dev/ which contains no Content-Type header when accessed.

% curl -I https://wrkr-direct-upload-test.pages.dev/
HTTP/2 200
date: Tue, 11 Oct 2022 23:23:11 GMT
access-control-allow-origin: *
cache-control: public, max-age=0, must-revalidate
etag: "a94c1f815ccc9bf387e0c393d8deafb3"
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=Y19jXStkJdOcwmpCsrIzk%2BOjl4CE0dQIcJFJ1nSZ6dt3RuXDB%2Fpj0pkxuxzfV8AnXB8QM%2FO4Q7zFPwFg66TJlRIt4MvmS%2B0I9hM3t4VVFk%2FKpmACaZoBVGsY0gBFMdt2B8I%2BnSesAeQX429VqAOl5lf%2BnjBk31Ctx7Xty6Nxj%2BY%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 758b57967b633779-MEL
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

Going to a non-existent page still returns a 404 Not Found and the appropriate 404 page, but all without Content-Type: text/html.

4

Can you share the code? I can’t duplicate this with my own but yours definitely has no content-type.

5

I uploaded the three files to https://github.com/coelmay/test-site which locally looks like

% tree test-site
test-site
├── 404.html
├── index.html
└── page1.html

0 directories, 3 files

It is the test-site directory that I uploaded to Cloudflare Pages. For reference, the same directory deployed manually to Netlify does work: https://wrkr-direct-upload-test.netlify.app

% curl -I https://wrkr-direct-upload-test.netlify.app/
HTTP/2 200
age: 43
cache-control: public, max-age=0, must-revalidate
content-type: text/html; charset=UTF-8
date: Wed, 12 Oct 2022 00:05:30 GMT
etag: "73e6cbb7f3148723b02dff27af24de62-ssl"
server: Netlify
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-nf-request-id: 01GF4R6QVDERHMMBCKQGSMSM0J
content-length: 444
6

Just for s**ts & giggles, I created another basic site with index.html and 404.html. Same thing.

Then added a _worker.js with to set a custom header. That works, but still renders as text/plain

7

Hrm.

https://testsite-2fw.pages.dev ← direct upload via wranger, works.

https://testsite2-8pw.pages.dev ← direct upload via the dashboard, works.

What’s different? I’m using macOS, are you on Windows? What else?

8

Using macOS 12.5.1 (I know there’s an update, just too lazy!)

Using Firefox 105.0.3.

9

Upload the first site via Chrome, and it works: https://wrkr-upload-chrome.pages.dev/

So it’s an issue with Firefox? Or an issue with how Firefox and Cloudflare interact?

10

I tried it with Firefox, both as a directory upload and a zip file, and it still works both ways for me.

11

Hmmm… Well, I got no idea then.

12

My initial upload was done on Windows 10 and Firefox.

13

Aha. I created a new project via Firefox and now have reproduced the bug.

Previously, I had created the project via Safari (worked) and uploaded a new deployment via Firefox (worked). Now I have a project created via Firefox (no content-type) and if I upload a new deployment via Safari, still no content-type (in fact, returning no content at all). https://testsite3.pages.dev

And now I’ve uploaded a new deployment via Safari as a directory rather than a zip file, in the same project, and it works again. :man_shrugging:t2: weird

@Walshy might be our only hope.

1 Like
14

Excellent (right?) that you could recreate this @i40west.

I also tried Firefox Nightly (107.0a1) as it has no extensions enabled, with the same result. Not sure when I originally saw this, but perhaps Firefox 103 or earlier.

15

I’ve still not been able to repro myself… seems to be something Firefox related but it’s weird since it shouldn’t matter at all what browser is used. We do the type stuff server side not client but yeah…

We’re aware of the bug just no idea how it’s caused yet and repro is hard.

2 Likes
16

I just ran into this issue myself on Firefox 107.0 on macOS Monterey (12.5.1). I created the project in Firefox and then dragged a folder for a direct upload. That led to my index.html page being served as plain text. I then created a zip and uploaded that as a new deployment and had the same issue. I then tried uploading the zip via DuckDuckGo (which is Safari in privacy clothing) and continued to have the same issue. I subsequently deleted the project.

But if I did the entire process via DuckDuckGo (project creation and zip upload), everything works.

The project is python-launcher.pages.dev if there’s some logging you can look into to see what’s going on.

17

Also running into this today as we test out Cloudflare pages.

site is at test-btc.pages.dev with a simple index.html and a 404.html.

we deployed a few times but it never serves with a content type header.

didn’t expect this would matter but yes the uploads is done via firefox :man_shrugging:

@Walshy let me know if I can help with fixing the issue

18

Hey,

Apologies for the issues, this bug shouldn’t happen and definitely shouldn’t be browser specific. It’s a very weird one and sadly very hard to repro.

Could you capture a HAR reproing this and send it over to me? (email [email protected])

1 Like
19

My environment is Firefox 109.0 on Win 10 and I encountered the same problem.

After reading this thread, I experimented direct uploading from ff and chromium, and I have these results:

  • Pages project created by Firefox , a folder of files uploaded by Firefox => text/plain
  • Pages project created by Firefox , a folder of files uploaded by chromium => text/plain
  • Pages project created by chromium, a folder of files uploaded by Firefox => text/plain
  • Pages project created by chromium, a folder of files uploaded by chromium => text/html (expected)

As a Firefox user I have to keep a chromium installed in case.

21

In my previous reply, I didn’t consider Cloudflare’s storage cache. Now I noticed if the file itself is unchanged, the malfunctioned files uploaded from Firefox won’t be updated (then corrected) by re-uploading from Chromium (due to cache mechanism I guess). So my experiment result might be wrong in the previous reply.

BTW, I found one more related problem. If a UTF-8 encoded file is uploaded from Firefox, it will be processed as if it’s a ISO 8859-1 codec file.
In contrast, UTF-8 file uploaded from Chromium will be correctly treated as UTF-8.