TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Empty image src can destroy your site

41 pointsby mkabout 15 years ago

9 comments

benologistabout 15 years ago
If your site is so delicately balanced that a single extra request can bring it to its knees then you have larger problems than a blank img tag.
评论 #1200076 未加载
pilifabout 15 years ago
this one also "works" with CSS background images by the way. I had one case during development here with ~10 elements that had a background image set to url() (in a style attribute. don't ask. please). And of course, that page was <i>really</i> taxing the server doing a complex calculation.<p>Of course, finding this was actually a good thing, because we could not only fix the empty background image but als fix the whole page so that a) the processing is done in the background and b) the result is cached.<p>So if you are careful about your architecture, an empty image url or two really is a non-issue. If on the other hand, you are not careful, 10 empty image urls on the wrong page can really take down your machine.<p>There IS a difference between 50 and 500 concurrent users.
thereabout 15 years ago
alarmist headline - it's a minor inconvenience at best. possibly difficult to track down why there are such duplicate requests going to your site and where the empty img tag is, but it's hardly going to "destroy your site".
评论 #1199884 未加载
mossabout 15 years ago
My favorite thing about this article is that it made me stop and think through why the bug would actually exist in so many browsers.<p>I can make sense of the IE bug: "" doesn't start with a protocol, like "<a href="http://" rel="nofollow">http://</a>, so it's not a full URL. It doesn't start with "/", so it's not relative to the server root. Therefore, it must be a relative URL, and the browser tries to download the image named "" in the same directory as the page.<p>But the Safari and Chrome problem baffles me. To have happened in Safari, Chrome, and Firefox, it must be a pretty straightforward mistake, but I just can't see it. Anyone else have guesses?<p>(Safari and Chrome admittedly use the same rendering engine, but still, Firefox doesn't.)
teyeabout 15 years ago
Wouldn't his proposed method of returning nothing when URL==referer "destroy" a form that posts to itself (action="." or "")?
thomas11about 15 years ago
Depending on your web framework, this may cause problems unrelated to load. If the framework identifies components in the DOM tree via auto-generated IDs, the additional requests can cause these to be regenerated. In your JavaScript, or even somewhere in the server side code which didn't expect further requests, the old value might still be used, breaking the site.<p>I learned this the hard way recently while working on an Apache Wicket app, see my mailing list post: <a href="http://old.nabble.com/Nasty-problem-with-%22component-not-found%22-and-images--solved--td27337027.html#a27337027" rel="nofollow">http://old.nabble.com/Nasty-problem-with-%22component-not-fo...</a>.
gstarabout 15 years ago
Another workaround is to assign a data url to the image tag, then replace the source with javascript.<p>Something like &#60;img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"&#62;
Auzyabout 15 years ago
A second request wont destroy your website. Yes a second request takes a tiny bit more bandwidth, but realistically, its impact is nil.
评论 #1199907 未加载
cfpabout 15 years ago
Useful link with good timing; this just came up today for me.<p>Wasn't destroying my site, but good to fix regardless.