Closed
Bug 666238
Opened 13 years ago
Closed 13 years ago
Firefox 5 caching is incorrect. Location: directive not followed
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 618835
People
(Reporter: bugs, Unassigned)
References
Details
(Keywords: regression, reproducible)
Attachments
(2 files)
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.
Reporter | ||
Comment 1•13 years ago
|
||
BTW the following http headers are used:
Cache-Control: no-cache, must-revalidate
Expires: Sat, 11 Jan 1997 06:30:00 GMT
Reporter | ||
Updated•13 years ago
|
Keywords: reproducible
Version: unspecified → 5 Branch
Reporter | ||
Comment 2•13 years ago
|
||
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
Severity: major → blocker
Comment 3•13 years ago
|
||
Can you get a Regression Range and post the resulting Pushlog?
http://harthur.github.com/mozregression/
Reporter | ||
Updated•13 years ago
|
Summary: Firefox 5 caching is incorrect. Input fields are not submitted → Firefox 5 caching is incorrect. Location: directive not followed
Reporter | ||
Comment 4•13 years ago
|
||
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
Reporter | ||
Comment 5•13 years ago
|
||
Probably caused by the code changes for this
https://bugzilla.mozilla.org/show_bug.cgi?id=561276
Comment 6•13 years ago
|
||
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•13 years ago
|
||
> 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...
Reporter | ||
Comment 8•13 years ago
|
||
Two cases in the log: without cache + with cache
Attachment #541159 -
Flags: feedback+
Reporter | ||
Comment 9•13 years ago
|
||
(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•13 years ago
|
||
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...
Reporter | ||
Comment 11•13 years ago
|
||
Updated•13 years ago
|
Severity: blocker → major
Updated•13 years ago
|
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache
Updated•13 years ago
|
Blocks: 561276
Status: UNCONFIRMED → NEW
tracking-firefox6:
--- → ?
tracking-firefox7:
--- → ?
Ever confirmed: true
Keywords: regression
Comment 12•13 years ago
|
||
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...)
Reporter | ||
Comment 13•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
> 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•13 years ago
|
||
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•13 years ago
|
||
Perfect! Should I dup it?
Comment 18•13 years ago
|
||
Sounds like it, yes.
Comment 19•13 years ago
|
||
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...
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Comment 20•13 years ago
|
||
Clearing tracking noms - they're already set on the DUP
tracking-firefox6:
? → ---
tracking-firefox7:
? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•