5 ms·

Empty image src can destroy your site

41 points by mk 17y ago

gstar 17y ago
Another workaround is to assign a data url to the image tag, then replace the source with javascript. Something like <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">
there 17y 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".
- gamache 17y ago
  Consider a very popular website which runs on the last generation of software; that is, it is susceptible to the C10K problem (tl;dr: thread/process-based concurrency starts to choke at ~10,000 simultaneous connections, largely regardless of vertical scaling). The server, or each server in the pool, might run at 75% load normally. And then traffic doubles. It's easy to imagine the hurt.
  - enneff 17y ago
    Traffic won't double. Total traffic is all requests (images, stylesheets, scripts), not just requests to the root HTML page. Not only that, but the client's browser probably caches it anyway.
    - geoffb 17y ago
      You're assuming that your static assets (js, css, images) aren't served from a CDN (pretty much the standard at companies like Yahoo!). When your main server is serving just the HTML it's much more likely that your requests could double.
      - boucher 17y ago
        Maybe. It's still a bit alarmist though. For 99% of sites, it will barely have an effect. Best practices for websites serving millions of pages a day truly are different than for websites serving thousands of pages a day. They are also different for web apps versus largely static pages. There is too much emphasis on absolutes in the web development community.
      - enneff 17y ago
        Any website serving its assets from a CDN will be a) unlikely to make a mistake like this empty image src thing, and b) have a well-cached front-page that would be unlikely to impact on server load.
therealist 17y ago
http://fraudit.wordpress.com/ http://fraudit.wordpress.com/
Auzy 17y ago
A second request wont destroy your website. Yes a second request takes a tiny bit more bandwidth, but realistically, its impact is nil.
- ojilles 17y ago
  Agreed (and actually saw this on 40M pv/day site on the inside myself), most of the stuff is cached by definition. Still a bad thing tho.
pilif 17y 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 really taxing the server doing a complex calculation. 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. 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. There IS a difference between 50 and 500 concurrent users.
teye 17y ago
Wouldn't his proposed method of returning nothing when URL==referer "destroy" a form that posts to itself (action="." or "")?
benologist 17y 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.
- rgrove 17y ago
  If your site is one of the world's top three most-visited websites and every pageview generates a single extra request, then you bet your ass it's going to cause problems.
  - deleted 17y ago
    [deleted]
  - benologist 17y ago
    If your site is one of the world's top three most-visited websites and every pageview generates a single extra request and that brings you down, then like I said you've got bigger problems. Your infrastructure should not be so delicate that the difference between uptime and downtime boils down to a single extra hit per pageview. I'm doing 500 hits per second right now, do I care if it becomes 600 or 700? Not at all, because that's still a nice, safe, comfortable distance from my maximum capacity.
    - aaronblohowiak 17y ago
      Your "you've got bigger problems" then translates to "you should have capacity for at least double your normal traffic". Capacity planning is complex enough that I wouldn't make such a blanket statement so judgmentally.
      - benologist 17y ago
        One extra hit per pageview is not necessarily double your traffic, it's probably below a 1% increase a lot of the time.
    - rgrove 17y ago
cfp 17y ago
Useful link with good timing; this just came up today for me. Wasn't destroying my site, but good to fix regardless.
moss 17y 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. I can make sense of the IE bug: "" doesn't start with a protocol, like "http:// http://, 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. 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? (Safari and Chrome admittedly use the same rendering engine, but still, Firefox doesn't.)
thomas11 17y 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. I learned this the hard way recently while working on an Apache Wicket app, see my mailing list post: http://old.nabble.com/Nasty-problem-with-%22component-not-found%22-and-images--solved--td27337027.html#a27337027 http://old.nabble.com/Nasty-problem-with-%22component-not-fo....

41 points by mk 17y ago

gstar 17y ago

Another workaround is to assign a data url to the image tag, then replace the source with javascript. Something like <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">

there 17y 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".

gamache 17y ago
Consider a very popular website which runs on the last generation of software; that is, it is susceptible to the C10K problem (tl;dr: thread/process-based concurrency starts to choke at ~10,000 simultaneous connections, largely regardless of vertical scaling). The server, or each server in the pool, might run at 75% load normally. And then traffic doubles. It's easy to imagine the hurt.
- enneff 17y ago
  Traffic won't double. Total traffic is all requests (images, stylesheets, scripts), not just requests to the root HTML page. Not only that, but the client's browser probably caches it anyway.
  - geoffb 17y ago
    You're assuming that your static assets (js, css, images) aren't served from a CDN (pretty much the standard at companies like Yahoo!). When your main server is serving just the HTML it's much more likely that your requests could double.
    - boucher 17y ago
      Maybe. It's still a bit alarmist though. For 99% of sites, it will barely have an effect. Best practices for websites serving millions of pages a day truly are different than for websites serving thousands of pages a day. They are also different for web apps versus largely static pages. There is too much emphasis on absolutes in the web development community.
    - enneff 17y ago
      Any website serving its assets from a CDN will be a) unlikely to make a mistake like this empty image src thing, and b) have a well-cached front-page that would be unlikely to impact on server load.

therealist 17y ago

http://fraudit.wordpress.com/ http://fraudit.wordpress.com/

Auzy 17y ago

A second request wont destroy your website. Yes a second request takes a tiny bit more bandwidth, but realistically, its impact is nil.

ojilles 17y ago
Agreed (and actually saw this on 40M pv/day site on the inside myself), most of the stuff is cached by definition. Still a bad thing tho.

pilif 17y 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 really taxing the server doing a complex calculation. 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. 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. There IS a difference between 50 and 500 concurrent users.

teye 17y ago

Wouldn't his proposed method of returning nothing when URL==referer "destroy" a form that posts to itself (action="." or "")?

benologist 17y 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.

rgrove 17y ago
If your site is one of the world's top three most-visited websites and every pageview generates a single extra request, then you bet your ass it's going to cause problems.
- deleted 17y ago
  [deleted]
- benologist 17y ago
  If your site is one of the world's top three most-visited websites and every pageview generates a single extra request and that brings you down, then like I said you've got bigger problems. Your infrastructure should not be so delicate that the difference between uptime and downtime boils down to a single extra hit per pageview. I'm doing 500 hits per second right now, do I care if it becomes 600 or 700? Not at all, because that's still a nice, safe, comfortable distance from my maximum capacity.
  - aaronblohowiak 17y ago
    Your "you've got bigger problems" then translates to "you should have capacity for at least double your normal traffic". Capacity planning is complex enough that I wouldn't make such a blanket statement so judgmentally.
    - benologist 17y ago
      One extra hit per pageview is not necessarily double your traffic, it's probably below a 1% increase a lot of the time.
  - rgrove 17y ago

cfp 17y ago

Useful link with good timing; this just came up today for me. Wasn't destroying my site, but good to fix regardless.

moss 17y 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. I can make sense of the IE bug: "" doesn't start with a protocol, like "http:// http://, 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. 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? (Safari and Chrome admittedly use the same rendering engine, but still, Firefox doesn't.)

thomas11 17y 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. I learned this the hard way recently while working on an Apache Wicket app, see my mailing list post: http://old.nabble.com/Nasty-problem-with-%22component-not-found%22-and-images--solved--td27337027.html#a27337027 http://old.nabble.com/Nasty-problem-with-%22component-not-fo....