This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html Multipage: http://www.whatwg.org/C#img-load Complete: http://www.whatwg.org/c#img-load Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html Comment: <img> should maybe cache broken images If an <img> fetches something that fails to decode as an image, the spec doesn't put it in the "list of available images". Maybe we should still store a key in that case and the data being a special value indicating a broken image. This allows setting e.g. .src to something known-broken to fail immediately instead of end up fetching the resource again. Posted from: 210.95.255.149 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 OPR/21.0.1432.48 (Edition Next)
What do browsers do? I doubt they put anything in the list; it would mean that if you fix the server, the browser refuses to try again anyway.
I think they refetch. What I'd like to avoid is repeatedly refetching the same resource that is known to be broken, at least at the scope of one document. For instance if a document has two <img>s that point to the same URL (and the first one completes fetching before the second one is seen). What I have in mind now is having a separate list that just stores the keys and always respects HTTP cache semantics and doesn't allow copying entries between documents. So reloading a document would always refetch even if the resource allows caching.
I strongly recommend just speccing what browsers do and not trying to fix it. There's almost zero chance that there's anything you can change here that wouldn't cause some site to break, since this stuff is almost two decades old.
Actually at least Firefox 26 does cache the broken response. I made a mistake in my previous testing which prevented HTTP caching. http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-broken-cacheable.html But this doesn't necessarily need a new list, it could be explained by the HTTP cache I think.
https://bugzilla.mozilla.org/show_bug.cgi?id=648568
https://github.com/whatwg/html/issues/4480