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. ***
Having XMLHttpRequest detect the header sounds like a good idea to me, or even having the HTTP channel implementation do the detection.
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.
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. >
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
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
Created attachment 210642 [details] [diff] [review] v1 patch
Attachment #210642 - Flags: review?(benjamin)
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2
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?
it does: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#573 (it's also what Shift+Reload uses)
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
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 220.127.116.11?
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
You need to log in before you can comment on or make changes to this bug.