Handle WebP images without content length headers.

[sjudd]

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.

[dekuashe]

Just a note, if the content is gzipped (that is, the request contains Accept-Encoding: gzip and the response contains Content-Encoding: gzip), Content-Length isn't available and we're supposed to get the actual length by consuming the entire stream first, so that's one scenario where this could happen, even though images shouldn't be gzipped on a well-configured server anyway.

[sjudd]

So we also ought to be setting Accept-Encoding everywhere when downloading images, not just in the HttpUrlConnection fetcher.

[dekuashe]

Seems like that should cover it by itself?

[sjudd]

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.

[mufumbo]

@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?

[TWiStErRob]

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.