Firefox caches extension update file

RESOLVED FIXED in mozilla1.8.1

Status

()

Toolkit
Add-ons Manager
--
major
RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: Todd Agulnick, Assigned: Darin Fisher)

Tracking

({fixed1.8.1})

1.8.0 Branch
mozilla1.8.1
x86
Windows XP
fixed1.8.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
The extension manager when requesting an extension's update file doesn't bypass the cache, so users who don't restart their browser will never receive extension updates, even if they explicitly ask for them.

The extension manager appears to intend to bypass the cache, as it sets the request header "Cache-control" to "no-cache," but this does not bypass FF's internal cache -- only proxy caches on the network.

Either the extension manager should explicitly set "LOAD_BYPASS_CACHE," or perhaps nsIXMLHttpRequest should detect the no-cache request header and set that on the channel.
*** Bug 325633 has been marked as a duplicate of this bug. ***

Comment 2

13 years ago
Having XMLHttpRequest detect the header sounds like a good idea to me, or even having the HTTP channel implementation do the detection.
(Assignee)

Comment 3

13 years ago
Hrm... this has mostly never been a real deal breaker because people can always adjust their servers to send appropriate cache control headers.  The problem is that people often just serve update.rdf files as an ordinary static file.

I'm happy to make the HTTP code honor 'pragma: no-cache' and 'cache-control: <blah>' request headers as equivalents to the various cache validation load flags.

Feel free to either re-purpose this bug or create a new one that this one will depend on.

Comment 4

13 years ago
I do not serve the update.rdf with any cache control headers.

I would appreciate instructions on what cache control headers need to be sent with an update.rdf.  A URL to documentation would suffice.

Technologically, requiring cache control headers to implement correct updates is a bit odd (to put it mildly); also consider that some users want to host extensions and do not have the privileges to load mod_expire on their servers, which is required to customize cache control.


(In reply to comment #3)
> Hrm... this has mostly never been a real deal breaker because people can always
> adjust their servers to send appropriate cache control headers.  The problem is
> that people often just serve update.rdf files as an ordinary static file.
> 
> I'm happy to make the HTTP code honor 'pragma: no-cache' and 'cache-control:
> <blah>' request headers as equivalents to the various cache validation load
> flags.
> 
> Feel free to either re-purpose this bug or create a new one that this one will
> depend on.
> 
(Assignee)

Comment 5

13 years ago
Godmar, I agree that this is something that should be fixed in Firefox.  My point was that you can work around the problem ;-)

Send the following response header to defeat browser caching:

  Cache-control: no-cache
(Assignee)

Comment 6

13 years ago
A quick fix for Firefox is to change the setRequestHeader call with setting the loadFlags attribute of "nsIXMLHttpRequest.channel"

I'll write a patch for this shortly, and file a bug on fixing our HTTP implementation.
Assignee: nobody → darin
(Assignee)

Comment 7

13 years ago
Created attachment 210642 [details] [diff] [review]
v1 patch
Attachment #210642 - Flags: review?(benjamin)
(Assignee)

Updated

13 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2

Comment 8

13 years ago
Comment on attachment 210642 [details] [diff] [review]
v1 patch

Does setting this loadFlag also send the "no-cache" HTTP header to bypass proxy caches, or do we need to do that separately?

Updated

13 years ago
Attachment #210642 - Flags: review?(benjamin) → review+
(Assignee)

Comment 10

13 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Updated

13 years ago
Attachment #210642 - Flags: branch-1.8.1?(mconnor)

Comment 11

13 years ago
I just ran into this bug with a recent change to our update.rdf for our release last week.

any chance of this getting into a 1.5.0.2?

Updated

13 years ago
Attachment #210642 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
Darin, I just noticed this never made it onto the branch so I checked it in.

Checked in to MOZILLA_1_8_BRANCH for Firefox 2.0
Keywords: fixed1.8.1
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.