666238 - Firefox 5 caching is incorrect. Location: directive not followed

Status: RESOLVED DUPLICATE of bug 618835

(Core :: Networking: Cache, defect)

Description

[Jørgen Thomsen]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0

After upgrading from Firefox 4 to Firefox 5 our login page is no longer working.
The fields of this form are not submitted to the server, when caching is enabled, which is the default (network.http.use-cache = true )

<form name="MYFORM" method="post" action="">
<input type="text" name="user" size="32" value="" />
<input type="password" name="password" size="20" value="" />
<input type="submit" value=" Login " /> 
</form>

Reproducible: Always

Steps to Reproduce:
1. Display http://xxx.tld/login.php
2. Fill form fields and submit form (form action = '')
3. 

Actual Results:  
The form fields are not submitted in the request

Expected Results:  
Form fields submitted

Disabling network.http.use-cache in about:config causes the form fields to be submitted. Switching between false and true reproduces the bug.

Comment 1

[Jørgen Thomsen]

BTW the following http headers are used:

Cache-Control: no-cache, must-revalidate
Expires: Sat, 11 Jan 1997 06:30:00 GMT

Comment 2

[Jørgen Thomsen]

After further testing and tracing it appears, that it is the FF5 caching logic about redirections which is defective. 
If a Location: URL2 header once has redirected URL1 to URL2 and further on to URL3, then FF5 will shortcut the process and redirect URL1 to URL3 and not obey the next Location: URL2 directive.

This is a major bug. Session data from the server may cause the URL2 to not issue a Location: URL3 but instead do something quite different.

This has been verified by comparing the packets sent and received in both a FF5 and an Opera session

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Can you get a Regression Range and post the resulting Pushlog?
http://harthur.github.com/mozregression/

Comment 4

[Jørgen Thomsen]

Last good nightly: 2011-03-24 First bad nightly: 2011-03-25

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=741701875a
ec&tochange=e11c2f95f781

Comment 5

[Jørgen Thomsen]

Probably caused by the code changes for this 
https://bugzilla.mozilla.org/show_bug.cgi?id=561276

Comment 6

[Bjarne (:bjarne)]

Sounds bad...  is there a publicly available site I can connect to, or could you follow the instructions on https://developer.mozilla.org/en/HTTP_Logging and attach the log here?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Session data from the server may cause the URL2 to not issue a Location: URL3
> but instead do something quite different.

In which case URL2 should be sending "Vary: cookie", right?  Looking forward to that url or log...

Comment 8

[Jørgen Thomsen]

Attachment: FF5 trace

Two cases in the log: without cache + with cache

Comment 9

[Jørgen Thomsen]

(In reply to comment #7)
 
> In which case URL2 should be sending "Vary: cookie", right?  Looking forward
> to that url or log...

Vary: cookie does not change anything

Comment 10

[Bjarne (:bjarne)]

Comment on attachment 541159 [details]
FF5 trace

Hmm...  I'm afraid I forgot to ask you to add ",cache:5" to the end of NSPR_LOG_MODULES - sorry about that! Any chance you could run and capture this again with cache:5 set? And please make separate logs if one run is with the cache disabled...

Comment 11

[Jørgen Thomsen]

Attachment: Trace with cache:5

Comment 12

[Bjarne (:bjarne)]

Just a question: When bisecting to find the regression-range, did you also search builds after 2011-06-11? I would expect bug #618835 to fix this.

(Is there any chance I can get access to the url you're using, btw? Makes it a lot simpler to try out things...)

Comment 13

[Jørgen Thomsen]

Sorry, you would need a password to our internal site. This is out of the question.

Last good nightly: 2011-06-12 First bad nightly: 2011-06-11

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e37011790a8a&tochange=dc8d154f3710


This bug introduced in FF5 is breaking sites, not only a minor inconvenience.
A release of FF5 fixing this should be released as soon as possible.

Comment 14

[Bjarne (:bjarne)]

(In reply to comment #13)
> Last good nightly: 2011-06-12 First bad nightly: 2011-06-11

Bz, you know how bad I am at this...  does this mean that something checked in at 2011-06-11 (e.g bug #618835) fixed the issue?

Comment 15

[Jason Duell]

> Last good nightly: 2011-06-12 First bad nightly: 2011-06-11

Jørgen,

Do you have those dates reversed?  Is the last good nightly the 11th, and then it's bad from the 12th on?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment 4 says something checked in between March 24 and March 25 broke this.

Comment 13 says something checked in between June 11 and June 12 fixed this.

So yes, I think bug 618835 fixed this.

Comment 17

[Bjarne (:bjarne)]

Perfect! Should I dup it?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Sounds like it, yes.

Comment 19

[Bjarne (:bjarne)]

Agreed. For the record: Log shows a POST (line 1360) resulting in a 302 back to the first (or second, actually) uri in the chain, which is exactly what bug #618835 deals with. Duping it...

Comment 20

[Johnathan Nightingale [:johnath]]

Clearing tracking noms - they're already set on the DUP