Closed Bug 490949 Opened 12 years ago Closed 12 years ago

bmp image served from router fails to reload despite Cache-control: no-cache directive

Categories

(Core :: ImageLib, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: erik, Assigned: joe)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.9.1)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.0.7, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.0.7, Ant.com Toolbar 1.3 (.NET CLR 3.5.30729)

My D-Link DIR 655 login page has a graphical authentication verification (like captcha). On a wrong password, a javascript displays an error box and calls "location.reload(true);"
However the graphical verification is not refreshed.
I traced on linux the http headers for that graphical verification (which is a bmp image).
Cache-control: no-cache\r\n
Server: Ubicom/1.1\r\n
Content-Length: 9454
Content-Type: image/bmp\r\n

I don't see any particular reason why firefox is not reloading the bmp...
This works perfectly with 3.0 and IE.


Reproducible: Always

Steps to Reproduce:
1. Login to DLink access page
2. Enter a wrong password
3. Click OK
Actual Results:  
Page refreshed but not the captcha

Expected Results:  
new captcha refreshed
Version: unspecified → 3.5 Branch
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Version: 3.5 Branch → 1.9.0 Branch
I can't reproduce this, even in 3.0. :( I'm working on a mochitest for this behaviour that I'll upload when it's ready.
Whoops, spoke too soon. I've got both a working testcase and a fix for the 1.9.1/1.9.2 branch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.9.0 Branch → Trunk
This test loads images with Cache-Control: no-cache, and does a location.reload(true) and location.reload(false) to make sure we always reload the image from the network when Cache-Control: no-cache is specified, even if we don't do a force-reload.
Assignee: nobody → joe
The image loading routines check if we're loading while bypassing the cache, but unfortunately that only handled the flags we pass in directly to imgLoader::LoadImage(), not those passed in indirectly via the load group. This made for a weird mismatch between LoadImage, which directly used aLoadFlags, and the methods it called, which used the harmonized load flags stored in requestFlags.

Luckily, this only affected loads that were to bypass the cache.

This problem also exists in 3.0/1.9.0, but I don't think it's necessary to fix there. Fixing for 3.5 should be enough, though we obviously shouldn't block.
Attachment #376061 - Flags: review?(vladimir)
Strangely enough, this issue doesn't happen with Firefox 3.0 - for some reason location.reload(true) works and reloads the bmp. I wouldn't bother fixing it for 3.0.
Checked in to mozilla-central:

http://hg.mozilla.org/mozilla-central/rev/bd22fde8a8a4
http://hg.mozilla.org/mozilla-central/rev/b6a74601ee1d

If there are no problem with this, I'll ask for approval for 1.9.1.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #376061 - Flags: approval1.9.1?
Comment on attachment 376061 [details] [diff] [review]
Take into account the load group's load flags when checking the cache

a191=beltzner
Attachment #376061 - Flags: approval1.9.1? → approval1.9.1+
The mochitest for this bug hasn't been pushed to 1.9.1. Is there a reason why?
Flags: in-testsuite?
Blocks: 658925
You need to log in before you can comment on or make changes to this bug.