302 status ignored if page previously set an etag




9 years ago
8 years ago


(Reporter: dennispopel, Unassigned)


1.9.1 Branch
Windows Vista

Firefox Tracking Flags

(Not tracked)



(2 attachments)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

1. A script initially sends an Etag header
2. Firefox sends back Etag header, script detects that content not changed, replies with 304, all is OK
3. After some content changes on site, the above script sends 302 (and ETag: 0  and Location: new-url), but Firefox ignores it and continues to show cached content instead of fetching new url. Tamper Data shows that the response status code is 302, and that Firefox did send the if-none-match header.

IE8 does not have this (buggy) behaviour.

Reproducible: Always

Steps to Reproduce:
1. Send an arbitrary Etag to the browser
2. On the same URL, send 302 status and Location: header
3. The new location will be ignored.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → 1.9.1 Branch

Comment 1

8 years ago
I can not reproduce this for 1.9.1, 1.9.2 nor trunk. Is there anything which indicates that this is a real problem anymore?

Comment 2

8 years ago
Hmm...  I downloaded and compiled the tarball for 3.0.11 as well (version indicated in comment #0) and still cannot reproduce. Maybe something wrong with my test or possibly not an accurate description? Could reporter indicate whether this has been resolved or is still a problem?

Comment 3

8 years ago
Could you please post your test script? Firefox is now 3.6 on my local box, and the original test script is all gone by now. I can rebuild it, but it will take more time than you pasting your test script here.
Thank you.

Comment 4

8 years ago
Created attachment 483768 [details] [diff] [review]
Xpcshell-test for 1.9.2 and trunk

Note the way requests are triggered to ensure each one finishes before the next one is requested, If the channels are async_opened as consecutive statements we run into issues which fails the test (which probably are bugs in themselves, but not what's described here).

Comment 5

8 years ago
Any update on this one?

Comment 6

8 years ago

I just created a simple PHP test script so I could test it under local Apache. Gecko does not reproduce it anymore.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME

Comment 7

8 years ago
Ok - thanks for your time. Feel free to attach the script for future reference.

Comment 8

8 years ago
Created attachment 485275 [details]
PHP test script

This is a simple PHP test case
You need to log in before you can comment on or make changes to this bug.