Repository navigation
Conversation
|
@renefloor could this be reviewed ? using magic bytes is preferred over a potentially missing extension |
settings.gradle and pubspec.yaml conflicted on lines main has since moved past (kotlin 2.3.20, build_runner ^2.14.0), so main's lines are kept. image_cache_manager.dart reformatted with dart format. Co-Authored-By: Claude <noreply@anthropic.com>
|
|
The resizer decided whether a file could be resized from the extension of the file on disk. That extension is derived from the url, so images served from extension-less urls, or from urls whose extension does not match the payload, were never resized. It also treated any zero-prefixed binary as an ico. - Detect jpeg, png, ico, cur and webp by their magic number, reading 12 bytes instead of 8 (webp needs the RIFF/WEBP marker at offset 8). - Keep an extension fallback for formats without a signature at the start of the file, like tga, which only stores a signature in its footer. - Read the header in a helper that always closes the file handle. - Restore the trailing newline in example/android/build.gradle, which was dropped by an earlier commit in this branch. - Bump to 3.4.6 with a dated changelog entry, as CONTRIBUTING now requires. Tests: cover an image served without an extension and a non-image payload served with an image extension.
|
Pushed a follow-up on top of your merge — thanks for resolving the What changed in
Tests in Also bumped to 3.4.6 with a dated changelog entry per CONTRIBUTING, and restored the trailing newline in
|
Flutter decodes bmp and wbmp as well, so they are resizable too. Bmp has a 'BM' signature and can be detected from the content. Wbmp starts with a two byte header that is too generic to match on, so it joins tga in the extension fallback.
|
Follow-up: added bmp ( Wbmp is in Flutter's list of decodable formats, but it cannot be detected from the content: its header is Gif is intentionally left out: it is decodable, but |
Two bytes (the SOI marker) are enough to tell jpeg apart from the other formats that are checked, which is what SDWebImage and most detectors do. A file that is detected as an image but fails to decode then errors out of getImageFile, as it already did for a mislabeled extension before this change.
The extension that was passed to putFile came from the cached file path. For a url without an extension that path ends in the key itself, so the extension contained a slash and putFile failed to create the file. This is what the new test for an extension-less url caught. The resized image is always encoded as png anyway, so name it png instead of copying the extension of the url.
The resizer always re-encodes the image to png, which keeps a single frame. Now that webp is recognized by its signature, an animated webp would enter the resizer and silently lose its animation. That is the same reason gif is not recognized at all. Read the flags of the VP8X chunk, which is where an extended webp marks itself as animated, and pass those files through untouched. A static webp, with or without a VP8X chunk, is still resized.
A tga without an id field and without a colour map starts with the same four bytes as an ico or a cur, so the signatures cannot be told apart. It does not affect the result, since all of them are resizable, but it looks like a mistake without the note.
3 participants
✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)
Bug fix.
When the http response's Content-Type is not image and the _resizeimage is not work.
🆕 What is the new behavior (if this is a feature change)?
The new method is get files extension with the file's binary data.
💥 Does this PR introduce a breaking change?
No.
🐛 Recommendations for testing
📝 Links to relevant issues/docs
🤔 Checklist before submitting