25798 2014-05-19 08:08:02 +0000 <img> should maybe cache broken images 2019-03-29 20:58:50 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED http://www.whatwg.org/specs/web-apps/current-work/#img-load P3 normal Unsorted 1 contributor ian d ian johns mike zcorpan contributor oldest_to_newest 106312 0 contributor 2014-05-19 08:08:02 +0000 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) 106616 1 ian 2014-05-21 20:23:59 +0000 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. 106701 2 zcorpan 2014-05-23 10:41:47 +0000 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. 106735 3 ian 2014-05-23 19:53:33 +0000 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. 107130 4 zcorpan 2014-06-02 14:09:14 +0000 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. 107923 5 zcorpan 2014-06-17 07:32:52 +0000 https://bugzilla.mozilla.org/show_bug.cgi?id=648568 129689 6 d 2019-03-29 20:58:50 +0000 https://github.com/whatwg/html/issues/4480