User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 I found this problem when developing a rotating logo to different pages in my community site. The rotating logo is based on a php script which is called from an <img> tag, which in returns sends an HTTP 302 to the real picture (gif). The php script checks for the referer, if it contains a specified string, it will redirect to a certain image. There are numerous checks like that, and if all of them fail, the default image is used. I have verified that my "system" works in IE, Opera & Mozilla 1.5 (not firebird!) well, 100% of the time. In the URL I have given, the logo that the script would redirect to is: http://www.fresh.co.il/dcforum/Army/army-logo.gif, but in my FB 0.7 it redirects to the default one: http://www.fresh.co.il/dcforum/logo.gif. This has no reason to happen but the lack of referer information, because I know that the rest of the logic of my script is fine, because all the rest, which is NOT browser-dependant, works well in any other browser that I tried :) Reproducible: Always Steps to Reproduce: 1. Surf into http://www.fresh.co.il/dcforum/dcboard.cgi 2. Surf into http://www.fresh.co.il/dcforum/dcboard.cgi?az=list&forum=Army&conf=Public 3. You should see two different logo's at the right top corner of the page. Actual Results: I saw the same (wrong) logo, because the browser probably doesn't send a referer header on <img> requests. Expected Results: Show a different (correct) logo.
Yes, I see this problem, and I think I have a much better explanation for it. I think the browser is caching the image with the given URL and showing it each time instead of re-requesting it at all subsequent times. I have proved to myself that this is what is happening by loading the first page, then clearing the cache before clicking on the link to the second page (http://www.fresh.co.il/dcforum/dcboard.cgi?az=list&forum=Army&conf=Public) This results in the correct image being loaded on the second page (army guy silhouette). With a clear cache, I can also surf to the second page and see the correct image (army guy silhouette) and then without clearing the cache, surfing back to the first page and see the wrong one for that page (still the army guy silhouette). So this seems pretty clear what is happening. "This has no reason to happen but the lack of referer information, because I know that the rest of the logic of my script is fine..." In light of the information I have just given, this assertion no longer seems true. Your script is probably fine. But the only thing we definitely know is that for two images with the same URI but embedded in different documents, Firebird displays whichever one of the images that was loaded first for both images. Until we see some client or server side verification (the webserver's logs, for example), there is nothing to prove that a request is even being made to the server for the second image, and therefore no reason to conclude that missing referral information has anything to do with this. I suggest you do not waste time getting that information. I think there is probably metadata in the server's response that Firebird is ignoring that other browsers pay attention to, such as an expires header or a cache control directive (or simply the fact that it's a 302?). Without knowing the details of how these work as implemented by Firebird, I still think this is the most likely scenario.
Re. ShepQ's Comment: Just now I browsed directly to my page with the non-default logo. The correct logo appeared. Browsing some more in the site, returned my old logo... Appears that the assumption is correct, the question is: who is to blame. Should I add some header in the server response of the 302? Is that even possible, to combine more headers when a 302 is sent? Will the browser "consider" cache control headers? Here are the headers sent from the webserver when sending true info: # telnet www.fresh.co.il 80 Trying 220.127.116.11... Connected to backbone.fresh.co.il (18.104.22.168). Escape character is '^]'. GET /scripts/logo.php HTTP1.1 Host: www.fresh.co.il Referer: http://www.fresh.co.il/dcforum/dcboard.cgi?az=list&forum=Army&conf=Public HTTP/1.1 302 Found Date: Sat, 01 Nov 2003 16:14:44 GMT Server: Apache/2.0.47 (Unix) Location: http://www.fresh.co.il/dcforum/Army/army-logo.gif Vary: Accept-Encoding,User-Agent Content-Length: 0 Connection: close Content-Type: text/html; charset=windows-1255 Connection closed by foreign host.
OK, I added some headers to the php script. Now the request looks like this: # telnet www.fresh.co.il 80 Trying 22.214.171.124... Connected to backbone.fresh.co.il (126.96.36.199). Escape character is '^]'. GET /scripts/logo.php HTTP1.1 Host: www.fresh.co.il Referer: http://www.fresh.co.il/dcforum/dcboard.cgi?az=list&forum=Army&conf=Public HTTP/1.1 302 Found Date: Sat, 01 Nov 2003 17:49:15 GMT Server: Apache/2.0.47 (Unix) Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Location: http://www.fresh.co.il/dcforum/Army/army-logo.gif Vary: Accept-Encoding,User-Agent Content-Length: 0 Connection: close Content-Type: text/html; charset=windows-1255 Connection closed by foreign host. Still, the logo remains the last one loaded. That means that FB is directly disobeying cache control headers (which is a common IE behavior, but not FB ;)). Clicking shift+hitting the reload button, and the logo is replaced to the right one. Moving to an other page, and the logo remains what it was before (and now is wrong). I consider that a verified bug from now, because AFAIK, a browser should never cache something if it recieves a "No-Cache" header about it. Correct me if I am wrong :)
>I consider that a verified bug from now No question the behavior identified is a bug. If I understand you correctly, you're agreeing with my assessment of what's happening. So the bug summary really needs to be changed. By the way, when I view page info (Ctrl+J) and select the image in question, its location is reported as "Memory Cache". In case we needed further proof, there it is. The following may be useful at some point, if this bug is going to get fixed: [From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Section 10.3.3, the HTTP/1.1 spec] "10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field." Firebird seems to ignore the rule inherent in last sentence. I would have guessed that Firebird is caching the content of the 302 response _unless_ a cache-control header says _not to cache it_, rather than caching it _only if_ a cache-control header says _to cache it_. Except that with your added cache-control headers, this possibility seems ruled out. So maybe I'll root around the source looking for why this happens. We probably need some help from someone who knows the source a little better.
*** This bug has been marked as a duplicate of 89419 ***