-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle WebP images without content length headers. #470
Comments
Just a note, if the content is gzipped (that is, the request contains |
So we also ought to be setting Accept-Encoding everywhere when downloading images, not just in the HttpUrlConnection fetcher. |
Seems like that should cover it by itself? |
Yes, though it depends on how paranoid we want to be. If someone adds a new http library (in addition to HttpUrlConnection, OkHttp, or Volley), they may not add the correct headers. Or someone could always decide to try enabling gzip manually, which would replace our attempt to set the header. Probably though you're right, the first thing to do is to add the headers everywhere (probably by making them defaults in LazyHeaders), then we can worry about other cases. |
Progress towards bumptech#470.
Progress towards bumptech#470.
@sjudd can you please tell me till what android sdk version glide supports webp now? is it well defined or the bugs are still randomly versioned? |
As far as I know, WEBP was and is supported where Android SDK can load webp by itself. This issue is about servers who respond with gzipped webp content, which is usually pointless, because they're already compressed. The problem is that they also don't send a length, which is required by some Android versions, see #392 for more. |
If we don't get a valid content length, we could check if the image is a WebP image on a version of Android affected by the framework bug and read the contents into a byte array. Although it's a bit of a hack, it would be a more robust solution than just checking content length headers and it wouldn't sacrifice too much performance on platforms not affected by the framework bug.
We could also log an error when reading into a byte array indicating that we think there's a problem with the headers so that developers who are able to do so can fix the root cause.
The text was updated successfully, but these errors were encountered: