502299 - 302 status ignored if page previously set an etag

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[dennispopel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.11) 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:1.9.0.11) 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.

Comment 1

[Bjarne (:bjarne)]

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

[Bjarne (:bjarne)]

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

[dennispopel]

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

[Bjarne (:bjarne)]

Attachment: 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

[Bjarne (:bjarne)]

Any update on this one?

Comment 6

[dennispopel]

Hello,

I just created a simple PHP test script so I could test it under local Apache. Gecko 1.9.2.10 does not reproduce it anymore.

Comment 7

[Bjarne (:bjarne)]

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

Comment 8

[dennispopel]

Attachment: PHP test script

This is a simple PHP test case