[Cloudflare image resizing] persistent Error 9412 /HTTP 415 (apparently no origin revalidation)
Hi, please direct me to a different channel if it fits better elsewhere. I am doing worker image resizing as described here: https://developers.cloudflare.com/images/image-resizing/resize-with-workers/.
Works as designed in general, but when I bulk add images to the origin storage (public Azure Blob Storage), while some of the new images are already requested through the worker, we sometimes get images that are stuck in an error state.
These requests then always return
HTTP 415 Unsupported Media type and Cf-resized: err=9412 long after the origin image upload is complete (~ 60 min.) The only way to fix this is to purge the complete cache in the dashboard manually.
I did a lot of debugging, and I don't see why Cloudflare does not revalidate the origin.
- There is no custom caching in the worker
- The origin does not send cache-control headers.
- Manually purging a single upstream URL as described here https://developers.cloudflare.com/images/image-resizing/troubleshooting/#caching-and-purging does not work. (So it is some kind of cache issue)Resize with Cloudflare Workers · Cloudflare Image Optimization docs
Using Image Resizing with Workers gives you powerful programmatic control over every image request.
Troubleshooting | Image Resizing · Cloudflare Image Optimization docs
Does the response have a Cf-Resized header? If not, then resizing has not been attempted. Possible causes:
1 Reply
I tried to reproduce the origin state changes during the upload and there is a timeslot (stage 2, ~10 sec) while the upload is in progress where error 9412 /HTTP 415 seems the correct response. As far as I can see, the stages are
1) HTTP 404 (
3) HTTP 200 (
Content-Type: application/xml, No Etag, No Cache-Control, No Last-Modified-At)
2) HTTP 200 (Content-Lenght: 0, Content-Type: image/jpeg, ETag: .., Last-Modified-At: ..., No Cache-Control)3) HTTP 200 (
Content-Lenght: ... , Content-Type: image/jpeg, ETag: .., Last-Modified-At: ..., No Cache-Control)
Stage 3 definitely returns the correct Image (it is picked up after the complete cache purge)
I can see that stage 2 should trigger Error 9412 /HTTP 415, but it sends no Cache-Control, a different ETag, and a Last -Modified-At that is before the stage 3 Last-Modified-At.
Any stage 3 revalidation requests from Cloudflare with If-Modified-Since or If-None-Match would return the full image (I double-checked with curl), but it seems that Cloudflare caches the upstream response of stage 2 forever.
Is this the expected behaviour? It only happens when there are resizing requests during stage 2 (That's why it never happened before going to production)