Last Comment Bug 224282 - Firebird violates RFC 2616 and caches a 302 redirection, although 302 means "temporarly moved". More over, It continues to do so even if Cache-Control headers specificly advise it to behave otherwise.
: Firebird violates RFC 2616 and caches a 302 redirection, although 302 means "...
Status: VERIFIED DUPLICATE of bug 89419
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Windows 2000
: -- normal (vote)
: ---
Assigned To: Blake Ross
:
Mentors:
http://www.fresh.co.il/dcforum/dcboar...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-31 03:17 PST by shimi
Modified: 2008-10-22 01:24 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description shimi 2003-10-31 03:17:46 PST
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.
Comment 1 Dave 2003-11-01 03:05:13 PST
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.
Comment 2 shimi 2003-11-01 08:18:50 PST
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 192.117.122.43...
Connected to backbone.fresh.co.il (192.117.122.43).
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.
Comment 3 shimi 2003-11-01 09:52:50 PST
OK, I added some headers to the php script. Now the request looks like this:

# telnet www.fresh.co.il 80
Trying 192.117.122.43...
Connected to backbone.fresh.co.il (192.117.122.43).
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 :)
Comment 4 Dave 2003-11-01 19:38:07 PST
>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.
Comment 5 Dave 2003-11-02 02:35:06 PST
Well, this is probably a dupe of Bug 89419 or Bug 168089, but it was an
interesting investigation.
Comment 6 Tom Mraz 2003-11-02 23:31:45 PST

*** This bug has been marked as a duplicate of 89419 ***
Comment 7 Simon Paquet [:sipaq] 2003-11-11 13:55:50 PST
verified.

Note You need to log in before you can comment on or make changes to this bug.