Comment 9 for bug 900959

It looks like we have two inter-related problems here:

1. The image size meta-data is incorrectly set to zero for remote images with no explicit size provided.

2. The image cache uses this bad size to set the Content-Length on the HTTP response to a GET of a cached image.

Issue #1 could be addressed most directly by the size meta-data being populated from the get-go by querying the backend store as to the actual size. For example in the case of the HTTP store, a HEAD request on the image URI would cheaply yield the Content-Length that would be returned on a full GET.

Another option would be to set the size to some initial value indicating unkown (e.g. -1), then lazily reset it to the real value when the image is retrieved for the first time (i.e. either pre-fetched or pulled down in response to a user's GET).

Issue #2 should also be fixed, as the cache would know the actual size of the locally cached image before returning it. In fact the HTTP response currently sent is not well-formed, as the Content-Length is zero-ized but the response body still contains the full image content.

So an initial work-around for the underlying problem could be to ensure the image cache sets the Content-Length to the actual cached file size as opposed to relying on the meta-data.

Thoughts?

If there are no objections to the above, I'll go ahead and put together patchs implementing the proposed changes.