If you are looking for the epic motorcycle journey blog that I've written, please see the Miles By Motorcycle site I put together. 
  • Nasty FireFox "bug" - empty img src= loads current URL.
    10/08/2008 7:41PM
    2008-10-15 Update:

    Unfortunately, it looks like MSIE 6, and possibly others, do not reliably set the HTTP_ACCEPT header to reflect the content type being requested. Often MSIE will send a */*.

    So at the present moment it's not clear to me how one can recognize a request on the server which resulted from an img src="" line.

    It looks like this is a known problem but no good solutions are provided for cases of user contributed content:

    http://brian.pontarelli.com/2006/05/02/is-your-browser-requesting-a-page-twice

    There are a couple of hacks one could try such as using javascript to loop through the page looking for empty image tags or maybe doing some in-line filter operation on the server to check for the same. Apparently this double request behavior is actually according to the standard and it occurs in some form or another in many browsers. Extremely annoying.



    Unfortunately this does not work for MSIE:

    Let's say you have a simple PHP script on a page such as:

    <?php

    if ( @$_SESSION["counter"] == NULL )
       $_SESSION[ "counter" ] = 1;
    else
       $_SESSION["counter"] += 1;

    print ("<h1>Counter is currently " . $_SESSION["counter"] . "</h1>" );
    ?>

    You would expect that counter would increment by 1 on each subsequent page load.

    HOWEVER, a case can arise where you notice the session counter increasing by more than one on each page load under FireFox but not under MSIE. This occurs, as was the case in some code I was working on today, when you have an empty <img src=""> in your document somewhere.

    In this case, FireFox will attempt to pull whatever the current page is as the source for the image, which will load your PHP script page and increment the counter "in the background".

    MSIE will attempt to load the default directory index of the current directory as opposed to attempting to load the current page which is why this issue is typically not visible under MSIE.

    In the static content case this is not much of a problem as you just have to make sure all of your references back to the server are correct. However, in the case of dynamically generated content and content provided by endusers you are much more likely to run into this situation.

    To guard against this case you can check the HTTP_ACCEPT request header before manipulating your session. This works in Firefox but not MSIE, unfortunately. I have not come up with nor found a good cross browser solution.

    if (( @$_SERVER[ "HTTP_ACCEPT" ] != NULL ) &&
       ( preg_match( "/^.*image.*$/", $_SERVER[ "HTTP_ACCEPT" ] )))
      {
      die();
      }


  • Comment By:
    -unknown
    10/15/2008 11:11AM
    Note: On reload, IE6 may return a regular expression "*/*"<br>
    in response to an HTTP_ACCEPT query.

    -dr
  • Comment By:
    Yermo
    10/15/2008 5:10PM
    Yea, my approach doesn't work. HTTP_ACCEPT from MSIE 6 is completely unreliable. There does not seem to be a good way of identifying whether or not a request is coming in as result of an img src=&quot;&quot; request or a page request. I've spent some hours researching it.&nbsp;
  • Comment By:
    -unknown
    10/15/2008 11:04PM
    The IE6 problem with HTTP_ACCEPT is apparently an old one.<br><br>
    There is a workaround mentioned by requesting a cookie from the server at:<br>
    http://throbs.net/web/articles/IE_Bug_with_HTTP_ACCEPT_...;
    expressed in Microsoft ASP shite, it goes:
    <br><em>
    'IE HTTP_Accept workaround: Cookie should last the duration of the browser's HTTP session.<br>
    IF Request.Cookies.Item("HTTP_ACCEPT") = "" THEN>br>
    &nbsb;&nbsb;&nbsb;&nbsb;&nbsb;Response.Cookies.Item("HTTP_ACCEPT") = Request.ServerVariables("HTTP_ACCEPT")<br>
    END IF</em><br><br>
    -drh<br>
You must be logged into an account to post comments.