views:

75

answers:

3

I'm getting weird 404 errors on my site for the following URL:

GET /%27%20+%20item.icon%20+%20%27 HTTP/1.1

I've got some corresponding code in my HTML file:

<script type="text/javascript">
  function foo(item) {
     return '<img src="' + item.icon + '">' : '';
  }
</script>

Seems to be coming from FireFox 3.5/3.6 on Windows only, but I can't guarantee that.

So, why would FF be requesting this URL? Is it trying to pre-load images or something? Any suggestions on how to stop it?

+6  A: 

Firefox is interpreting your code as XHTML. Try to put your code in a CDATA section like this:

<script type="text/javascript">
//<![CDATA[
  function foo(item) {
   return '<img src="' + item.icon + '">' : '';
  }
//]]>
</script>

See this page for a little more information about this problem.

piquadrat
Very annoying to reproduce, seem to need to quit FireFox, refresh and Ctrl+F5 won't cause the problem, only the first load of the page.
Tom
That's probably related to the browser cache. Firefox already knows there's nothing other than a 404 error coming back from that URL and doesn't bother to try it again. Restarting Firefox empties that cache.
piquadrat
I get that the page is invalid (X)HTML. However, my Firefox (3.5.7-ubuntu) still parses it into what you would expect (no `img` element in the `script` element). And LiveHTTPHeaders shows no bogus `img` request . I am confused about why the normal tag soup heuristics aren't applying here. Did this part of the parser change in 3.6? Tom, what does the DOM look like in DOM Inspector or Firebug?
Matthew Flaschen
Hmm, that seemed to fix it last night, but it's not working this morning. Maybe it was late... The page has an XHTML doctype and the script tag looks fine in the DOM inspector. The script tag is in the BODY. This issue doesn't occur in Ubuntu for me either, only Windows.
Tom
+1  A: 

Ok, turns out using the CDATA section didn't help after all. Fixed it by moving the function into a separate .js script file.

Tom
+1  A: 

I am having this exact same problem.

I can confirm that it's happening from Mac FF 3.6 as well. It's a 3.6 only thing. Even the 3.7 alphas seem to work, according to some people on IRC that I had try it out.

I can also confirm that the CDATA trick didn't work; I tried many variations. I also tried different DOCTYPES, etc.

I also have a horrible time reproducing it. It only happens about 30% of the time I load th page, even if I take the same steps each time w/r/t clearing the cache, restarting FF, etc. It's definitely a heisenbug. I can't produce a simple test case that works, either. The trigger conditions for this to happen must be pretty complex.

However, I have had some luck in fixing it. The key seems to be to kill the src=. So for instance:

var someHTML = '<img src="' + item.url + '" />';

becomes:

var someHTML = '<img s'+'rc="' + item.url + '" />';

So far this seems to be helping, but it hasn't been long enough for me to be sure.

This problem is particularly insidious in my case; I have a JSON string that has 20 URLs in it, and FF 3.6 requests all 20 URLs (which are bogus urls but end up hitting the same page) within a split second and DoS's the server every time someone with FF 3.6 visits my site.

This is a very bad bug in FF. I think that a lot of webmasters have yet to even discover that it's happening, but I'd imagine that it's causing widespread problems.

apinstein
Good idea breaking up the `src` attribute. As I mentioned in my answer, moving the code out into a separate `.js` file also does the trick.
Tom