318793 - Firefox caches extension update file

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Todd Agulnick]

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.

Comment 1

[Robert Strong (they/them - no direct email)]

*** Bug 325633 has been marked as a duplicate of this bug. ***

Comment 2

[Benjamin Smedberg]

Having XMLHttpRequest detect the header sounds like a good idea to me, or even having the HTTP channel implementation do the detection.

Comment 3

[Darin Fisher]

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

[Godmar Back]

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.
> 

Comment 5

[Darin Fisher]

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

Comment 6

[Darin Fisher]

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.

Comment 7

[Darin Fisher]

Attachment: v1 patch

Comment 8

[Benjamin Smedberg]

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?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

it does: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#573

(it's also what Shift+Reload uses)

Comment 10

[Darin Fisher]

fixed-on-trunk

Comment 11

[Jon Granrose]

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?

Comment 12

[Robert Strong (they/them - no direct email)]

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