Content-Type incorrect on www subdomain if no 'Accept' header?

Hi there,

On just my www subdomain if there’s no ‘Accept’ header sent then it returns the wrong content-type.

$ curl -s -H ‘Accept:’ -I -X GET https://www.domain.com/hi.jpg | grep type
content-type: text/html; charset=UTF-8

$ curl -s -H ‘Accept:’ -I -X GET https://domain.com/hi.jpg | grep type
content-type: image/jpeg

I only noticed as Discord preview images and a few other things weren’t showing up with my domain and I did some poking around.

If I ‘Pause Cloudflare on Site’ all is fine.

Any ideas?

Thanks,
Oli

The full headers might give more info… and it turns out any request, regardless of if the file exists or not will return this…

Dev mode is on at the moment.

$ curl -H ‘Accept:’ -I https://www.domain.com/hi.jpg
HTTP/2 500
date: Fri, 17 Sep 2021 16:08:04 GMT
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN
referrer-policy: same-origin
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
cf-ray: 69039754895f5953-AMS
server: cloudflare

$ curl -H ‘Accept:’ -I https://www.domain.com/thisfiledoesntexist
HTTP/2 500
date: Fri, 17 Sep 2021 16:12:34 GMT
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN
referrer-policy: same-origin
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
cf-ray: 69039ded2c3e4c49-AMS
server: cloudflare


Results with Cloudflare on/off:

$ curl -H ‘Accept:’ -I https://www.domain.com/hi.jpg
HTTP/2 500
date: Fri, 17 Sep 2021 21:19:35 GMT
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN
referrer-policy: same-origin
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
cf-ray: 69055fa47d7c6b45-AMS
server: cloudflare

$ curl -H ‘Accept:’ -I https://www.domain.com/hi.jpg
HTTP/2 200
server: nginx
date: Fri, 17 Sep 2021 21:20:37 GMT
content-type: image/jpeg
content-length: 51999
last-modified: Thu, 16 Sep 2021 16:10:24 GMT
etag: “61436c70-cb1f”
expires: Sat, 17 Sep 2022 21:20:37 GMT
cache-control: max-age=31536000
host-header: 8441280b0c35cbc1147f8ba998a563a7
x-proxy-cache-info: DT:1
accept-ranges: bytes

In the end it turned out I had an active Worker (sg_worker) that I disabled.

I’d never setup a Worker before, but had activated Cloudflare through my host’s (SiteGround) interface a while ago, before setting Cloudflare up myself for more control, so it must have be a holdover from that.