We don’t currently support webp as an input format so even with .webp file extension you will get the same error.
Is there anyway to serve png or jpg images?
I’m not sure if you can provide a direct URL to the source image before it is converted. From our side fetching from a CDN or direct from origin won’t make a huge difference except maybe taking slightly longer. We cache assets at our end for 24 hours so we re-use assets if they have already been downloaded.
Even if we serve a JPEG image, it still seems to fail because of the extension being different.
We’re linking directly to our image optimizer/resizer, so we’re doing required image manipulation work on the source image dynamically. Unfortunately, we don’t have the capability of returning the same type as the source image, we always convert to either AVIF/WebP/JPEG when the source image could be PNG (or anything).
Yes, if the real image type and the extension are not correct the render will fail. This is not a validation issue, it actually causes and error in our render engine.
I am thinking it may be possible to check the files mime type just before rendering and rename the file extension accordingly if it does not match.
This isn’t an overnight fix but should be something we can fix within a week.
Please can you provide me with some test URL’s and I can use those to check against in development? From what I understand this will be a PNG file with a JPG extension.
AVIF and WebP import and output are on our roadmap but no release date for those just yet.
We deployed a fix over the weekend to auto-detect the content type instead of relying on the extension. Now if you send a jpg file with a png extension or vice versa, we’ll detect it and handle it accordingly.
Please try again and let me know if you have any issues.
Looks to be working! We implemented a quick-fix on our side by implementing a middleman worker to redirect to a proxy URL using the correct extension, we’ll disable and let it run as normal and see if any other issues pop-up.