Er, ccing Joe too. Joe, see comment 1?
You could be right. I've seen two scenarios: 1. A response that is missing a content-type and doesn't contain an image 2. A response that has a non-image content-type and also doesn't contain an image I've not built out a test to see if an image served with a non-image content-type would cause the issue. For some background: the tracking beacons used by ads are frequently included as images in the page because there's no cross-domain restriction. They sometimes return images (1x1 tracking pixels) but don't necessarily always return images since the response isn't necessary to the experience...it's only necessary that the request reaches the server for tracking.
> I've not built out a test to see if an image served with a non-image > content-type would cause the issue. OK. For <img> loads, the Content-Type header is more or less completely ignored, so all that matters is the data that was returned.
If the prefetched-(non)image's cache expiration hasn't expired by the time the real <img /> load starts the "image" should probably NOT be downloaded again. If it has expired or has no expiration directive the (non)image SHOULD be redownloaded; as the contents of the url may have changed in brief interim between the prefetch and load-start. Right?
David, once we discover that the data is not an image we close the connection. So the non-image data never gets cached in its entirety.
I think that caching a non-image is just fine, actually! I'm also 100% certain that it will require some changes in the notifications sent by imagelib, because we never assume we're going to keep in-error images around.
Hey, guys. I'm poking you about figuring out what we want to do here. Maybe nothing is the right answer, but I'd like some forward progress and ownership. Thanks!
Let me see what I can do. :)
and it also happens, if the src-url is a non-image, that redirects to an image (e.g. in those tracking-pixels)