Image Resize Cloud .WEBP format returns Error 406

I got it in my WireShark

via: 1.1 image-resizing-proxy

Ok I found out that the Resizer Worker does not read that my IIS server can serve WEBP images

I tried with another location on the web a NGINX server and it works with my own worker THIS WORKS NGINX THIS DOES NOT WORK IIS

Why does CF not read that my IIS can service WEBP images and then send the wrong accept header

The issue is regards to IIS and CF. CF dont seem to query that the IIS support WEBP and thats why the accept type webp/image are not in the request headers. If anyone in CF staff can resolve this, it would be nice.

Installed a NGINX on a Debian and works flawless after 15 minutes installation :slight_smile:

But hope someone can investigate on this.


There are no issues with the backend, its CF Image Service that request with a wrong header

Could it be the MOD Rewrite Module or Helicon Ape HTAACESS ISAPI filters or FastCGI that modifies the headers? Is that what the beneath says. But why does it work for PNG and JPG then?

406 Not Acceptable ( RFC7231)

Resource is not available at the origin that adheres to negotiation headers that were set prior (e.g. via Accept-Charset and Accept-Language headers)

This status code can be replaced by simply serving the less preferred method to the User-Agent in lieu of generating this error.

1 Like

I have tried now with a clean Windows 2022 Server with IIS on. No HTACCESS module and it also fails. Whats up with this IIS thing. Hope someone can shine a light on this.

Using the real time log on CF I can see that no headers are send for the request from CF. How do I copy the original headers and transfers with the initial reguest from CF to the origin server

Can anyone reproduce this error also on a IIS server?

Post the code that you’re using in your Worker.

Of note, you should be parsing the Accept header yourself and setting the appropriate format as per the documentation: Resize with Cloudflare Workers · Cloudflare Image Optimization docs

Ok please note its not the final step in the worker that fails, but the initial request to origin server with the NEW Request function where request.headers are send as a parameter. But CF discards these and inserts only jpg,png and gid for IIS servers. NGINX works just fine im getting the correct original header.


const myrequestt = new Request(imageURL, {
headers: request.headers

Its not the request to the CF resize engine

return fetch(modifiedRequest, {cf:{image:resizingOptions}})

What you are referring to is the fetch command. That is not the function that gets the origin image.

Its ven i their own documentation

// Build a request that passes through request headers. These headers dont get to a webserver with IIS. As I wrote 100 times. Its like CF dont like IIS and dont think it supports WEBP. No problems with NGINX or Apache

const imageRequest = new Request(imageURL, {
headers: request.headers

Cloudflare has no way of knowing that you’re using IIS until it has received a response, at which point the request headers have already been sent.

I have a wireshark packet capture of it. It does send it in a different way. Its like there is some sort of cache or other feature blocking using a IIS. Thats why it would be nice someone to confirm that they can get it to work with an IIS. I tried iwth new isntalled machine on other public IP same issue.

Here is the request CF initiates

Full request from CF logstream to an IIS server. Headers in bold nothing that get send to the origin server. so CF inserts default i think witch is jp,png and gif

“outcome”: “ok”,
“scriptName”: “images”,
“exceptions”: ,
“logs”: [
“message”: [
“THE IMAGE adidas.webp”
“level”: “log”,
“timestamp”: 1660561158210
“message”: [
“level”: “log”,
“timestamp”: 1660561158210
“message”: [
“level”: “log”,
“timestamp”: 1660561158210
“message”: [
“level”: “log”,
“timestamp”: 1660561158210
“message”: [
“signal”: {
“aborted”: false
“fetcher”: null,
“redirect”: “follow”,
“headers”: {},
“url”: “”,
“method”: “GET”,
“bodyUsed”: false,
“body”: null
“level”: “log”,
“timestamp”: 1660561158210
“eventTimestamp”: 1660561158210,
“event”: {
“request”: {
“url”: “”,
“method”: “GET”,
“headers”: {
“accept”: “text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9”,
“accept-encoding”: “gzip”,
“accept-language”: “da-DK,da;q=0.9,en-US;q=0.8,en;q=0.7,nb;q=0.6,zh-CN;q=0.5,zh;q=0.4”,
“cf-connecting-ip”: “”,
“cf-ipcountry”: “DK”,
“cf-ray”: “73b16b86cd01abe0”,
“cf-visitor”: “{"scheme":"https"}”,
“connection”: “Keep-Alive”,
“host”: “”,
“sec-ch-ua”: “"Chromium";v="104", " Not A;Brand";v="99", "Google Chrome";v="104"”,
“sec-ch-ua-mobile”: “?0”,
“sec-ch-ua-platform”: “"Windows"”,
“sec-fetch-dest”: “document”,
“sec-fetch-mode”: “navigate”,
“sec-fetch-site”: “none”,
“sec-fetch-user”: “?1”,
“upgrade-insecure-requests”: “1”,
“user-agent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36”,
“x-forwarded-proto”: “https”,
“x-real-ip”: “”
“cf”: {
“clientTcpRtt”: 20,
“longitude”: “9.86060”,
“latitude”: “55.85720”,
“tlsCipher”: “AEAD-AES128-GCM-SHA256”,
“continent”: “EU”,
“asn”: 62319,
“clientAcceptEncoding”: “gzip, deflate, br”,
“country”: “DK”,
“isEUCountry”: “1”,
“tlsClientAuth”: {
“certIssuerDNLegacy”: “”,
“certIssuerSKI”: “”,
“certSubjectDNRFC2253”: “”,
“certSubjectDNLegacy”: “”,
“certFingerprintSHA256”: “”,
“certNotBefore”: “”,
“certSKI”: “”,
“certSerial”: “”,
“certIssuerDN”: “”,
“certVerified”: “NONE”,
“certNotAfter”: “”,
“certSubjectDN”: “”,
“certPresented”: “0”,
“certRevoked”: “0”,
“certIssuerSerial”: “”,
“certIssuerDNRFC2253”: “”,
“certFingerprintSHA1”: “”
“tlsExportedAuthenticator”: {
“clientFinished”: “4507ce9b3a0f13bf997a9806363c0cd1043593ccd88963e8f3e5d9a0b066a23f”,
“clientHandshake”: “1b52af5f71571f798ef1d8e6fb6a478e996964736928e829aab784e9bdf91ee0”,
“serverHandshake”: “0d24417ad773d4770bce3fb9c932e6d032cb061e272a691c49ff8a5c5dcda29e”,
“serverFinished”: “27ab479f180b778caec8a8a77d2116cabca9ef9a5b6bfe53ee8a04c809d05c0b”
“tlsVersion”: “TLSv1.3”,
“colo”: “CPH”,
“timezone”: “Europe/Copenhagen”,
“city”: “Horsens”,
“edgeRequestKeepAliveStatus”: 1,
“requestPriority”: “weight=256;exclusive=1”,
“httpProtocol”: “HTTP/2”,
“region”: “Central Jutland”,
“regionCode”: “82”,
“asOrganization”: “It Relation”,
“postalCode”: “8700”
“response”: {
“status”: 406
“id”: 0

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

sorry it took that long.
we extended Accept header with image/*;q=0.1

aforementioned link works now:,format=auto,fit=scale-down/images/categories/categoryhero_Performance.webp