Pages messes with mime types

Ticket # 2117079

BAD BAD BAD

I got this error in the web console when viewing my site in Firefox: The stylesheet https://a-view.org/style.main.min.5ea2f07be7e07e221a7112a3095b89d049b96c48b831f16f1015bf2d95d914e5.css was not loaded because its MIME type, “application/octet-stream”, is not “text/css”.

The site renders like garbage because the style sheet can’t be loaded.

I found this searching the forum in another context. This mime type does not occur in my content anywhere (I know–searched it all). It appears that Pages generates a new header record for the site that changes the mime type.

THIS IS YOUR BUG and I don’t know what I can do to fix it.

YOU MUST NOT ALTER PEOPLE’S CODE AND FILES!

That’s a bummer. Have you opened a ticket for the issue? If so, please post the ticket number for higher visibility.

Also worth raising this in the Workers Discord :slightly_smiling_face:

I did and someone responded. The person doesn’t know that a product called CloudFlare Pages exists and has no idea how it works. She asked for my web server logs. Of course, it’s CloudFlare’s server to which a user of “Pages” has no access.

I recommend mentioning this in Discord as @jb3 stated, the team watches the channel closely over there. For a temporary workaround you can probably modify the mime-type with Workers.

1 Like

Discord dialog was awesome. Got some hints on Worker to force mime type. Seems like it might attract right notice.

It might be helpful for others if you report the solution here, so that it’s not lost in the long conversations over there.

1 Like

They tell me I need to write a worker script to force the mime type of the generated site.

workers ARE A VERY HEAVY LIFT: most know javascript, tons of boilerplate, tons of fragile setup, pretty much need to know a lot about sysops. These are great skills to have but I don’t have them. (The Python approach has lots of dependencies that are more work than necessary–better to use JS.)

Can I hire someone to do this? My learning is several days up to weeks to do something that it will take someone skilled 30 minutes.

Otherwise, I have to wait for CF to fix what is obviously a bug. Not clear they care enough to work on a free service (gateway to hoping for upgrades to paid services…).

Any ideas?

Otherwise, it’s just not worth it to me. Hosting this Jamstack stuff is low value add and completely commoditized. There are some benefits to using CloudFlare’s CDN but my site is very low volume (that’s an over-statement). So, any one of the coolkid’s SSG deployment services will do. I have tried Render, Vercel, Netlify. All have pros and cons. Render has ok speed and the clearest UI.

Figured I’d update the folks here with the solution we found in the Discord :smile:.

Deploying a worker with the attached code and overwriting the Content-Type if the file type ends in .css worked and the site is now returning good CSS.

async function handleRequest(request) {
  let resp = await fetch(request.url, request);

  let newResp = new Response(resp.body, {
    headers: resp.headers,
    status: resp.status
  })

  if (request.url.endsWith(".css")) {
    newResp.headers.set("Content-Type", "text/css");
  }

  return newResp;
}

addEventListener("fetch", event => event.respondWith(handleRequest(event.request)))
1 Like

Thank you. I posted to Hugo Discourse. Can you talk to engineers/developers for Pages and get this fixed? The work around is ok, but it is a work around.

  • Lewis
1 Like

I’ve passed along the findings here to our Pages team. Thank you for the information!

1 Like