Closed Bug 415843 Opened 12 years ago Closed 12 years ago

[IE7] Internet Explorer 7 unable to download non-browser add-ons

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

x86
Windows Vista
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: imdaifne, Assigned: wenzel)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

When attempting to download a Thunderbird theme using IE by left clicking on the Install button results in an error. (See attached file). This happens on all themes that I tried to download from AMO. The same themes download properly using Firefox. 

Reproducible: Always

Steps to Reproduce:
1. Using IE, go to AMO>Thunderbird>Themes
2. Find a theme and left click on Install
3. Downloader starts, stalls and then brings up error. 


Expected Results:  
IE should be able to download the .jar file.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11)
> Gecko/20071127 Firefox/2.0.0.11
> Build Identifier: 
> 
> When attempting to download a Thunderbird theme using IE by left clicking on
> the Install button results in an error. (See attached file). This happens on
> all themes that I tried to download from AMO. The same themes download properly
> using Firefox. 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Using IE, go to AMO>Thunderbird>Themes
> 2. Find a theme and left click on Install
> 3. Downloader starts, stalls and then brings up error. 
> 
> 
> Expected Results:  
> IE should be able to download the .jar file.
> 

Forgot to mention that I'm using IE7 and one other user, at least, is also using IE7. http://forums.mozillazine.org/viewtopic.php?t=626084

First user to mention this has this user agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)
I am also experiencing this error when trying to download extensions for Thunderbird from AMO, using IE7.

Steps to Reproduce:
1. Using IE7, got to AMO>Thunderbird>Extensions
2. Find an extension and left-click install button.
3. Download dialog starts then error comes up.

Expected results:
IE should be able to download .xpi file. 
I'll admit that this bug makes me cry, but I see your points.  The .xpi download should be sent with Content-disposition: attachment; but we will try to figure out why IE doesn't like this.  Could be a combination of headers over SSL that violates IE's security model.

Relevent changeset is here:
http://tinyurl.com/2gwurw

This isn't a high priority, so feel free to pick it up.  Otherwise we won't be able to get to this until mid February.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks, Michael. 

It's not a big deal for me, since I rarely use IE, but we do see some Thunderbird users that don't use Firefox. 
I figure I am not helping, but what I found from googling real quick is that it "should work": http://support.microsoft.com/kb/260519
As per IRC today, this bug affects all add-ons on non-browser pages; the guess that it may be related to the Content-Disposition header is therefore a good one.
Summary: Attempt to download theme with IE results in error → [IE7] Internet Explorer 7 unable to download non-browser add-ons
The problem I am quite confident is causing it is the apparent inability of IE to download a file without caching it. We send no-cache headers when a file is served locally, causing IE to choke on the seeming contradiction "no-cache headers" vs. "downloading a file".

(Note that this behavior is not suggested by the HTTP/1.1 specification).
Wenzel is right. When doing a quick search, you'll find several posts on this subject:
http://www.php.net/manual/en/function.header.php#79029
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1589622&SiteID=1

An idea might be to check HTTP_USER_AGENT and don't set no-cache when it's IE.

There might be some issues involving HTTPS, but I think you can get around it with header("Pragma: public");
Duplicate of this bug: 427009
Duplicate of this bug: 427009
Component: API → Public Pages
QA Contact: api → web-ui
Target Milestone: --- → 3.4
We are talking about the same dictionary here; download worked from:


https://addons.mozilla.org/en-US/firefox/downloads/file/20968/wortliste_von_http___tkltrans.sf.net__alte_und_neue_deutsche_rechtschreibung_-20060716-fx+tb+sm.xpi


https://addons.mozilla.org/en-US/firefox/browse/type:3


but does not from:


https://addons.mozilla.org/en-US/thunderbird/downloads/file/20968/wortliste_von_http___tkltrans.sf.net__alte_und_neue_deutsche_rechtschreibung_-20060716-fx+tb+sm.xpi


https://addons.mozilla.org/en-US/thunderbird/browse/type:3



"Internet Explorer cannot download............

The file could not be written to the cache."



In each case the first address is found in "Properties" for the downlad, the second is what actually appeared in the address bar for the download.
Appears to also affect IE6 (I'm using IE6/WIN2000).  Successfully downloaded from alternate source given here: http://forums.mozillazine.org/viewtopic.php?p=3338417#3338417 by SkyPilot
Assignee: nobody → fwenzel
Target Milestone: 3.4 → 3.4.1
Duplicate of this bug: 429470
Jeremy, can you advise? The problem is that we are sending no-cache headers *and* we have an SSL server, the combination of which triggers an IE (version 5 to 7) bug.

We use "Pragma: no-cache" (and cache-control no-cache) headers for downloads being served off the app cluster.

Other web applications suffer from the same issue, like the CMS Plone: http://plone.org/products/cachefu/issues/117

Apparently changing to "Pragma: private" and "max-age: 0" will achieve the same (that is, making proxies revalidate the resource on every request), while not triggering the IE issue.

Do you see any problems with our current netscaler setup, or can I just change the headers in the code?
Status: NEW → ASSIGNED
Looks okay to me.  Mrz, do you see an issues in Comment 15?
I don't.  Change and test?
Yup, will need to push it to trunk for that. Is php5stage behind the netscaler? Or is preview (both of which update from trunk periodically, right?)

Thanks for now, will proceed with testing tomorrow.
Okay a test for these headers is in r12440 in the trunk. I'll try downloading a file with IE once the change shows up on php5stage (which, btw. is behind a netscaler).
Ah yes, that works now: I was able to download an experimental add-on off preview with MSIE7.

Stephend, to reproduce you may want to check downloading an experimental Thunderbird Add-on (when logged in) with IE, for example "ads4email" or any other. That fails atm. Then try the same on preview.amo, which should work thanks to the changed headers.

Thanks for the help, oremj and mrz.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: push-needed
Resolution: --- → FIXED
1) I can't successfully log in to preview (it just returns me to the homepage, logged out)
2) http://remora-trunk.php5stage.mozilla.com/en-US/thunderbird/downloads/file/14374/addressbook_groupdav_connector-0.56-tb.xpi just returns "Add-on not found!" even when logged in to that box.
1) I ran into the same problem yesterday with IE7 :( I cleared its cookies, then restarted the browser, then it worked.
2) It seems like remora-trunk.php5stage does not have a file repository, thus it cannot find the downloads.
Verified FIXED using 

1) Ads4Email 0.0.1:

https://preview.addons.mozilla.org/en-US/thunderbird/addons/policy/0/4809/14814

(which doesn't work on production, https://addons.mozilla.org/en-US/thunderbird/addons/policy/0/4809/14814).

2) FoxyTunes:

https://preview.addons.mozilla.org/en-US/thunderbird/addon/219

(which also doesn't work on https://addons.mozilla.org/en-US/thunderbird/addon/219)

Thanks to morgamic for making sure I _actually followed Fred's steps to verify the bug_; I was running into "Add-on not found!" problems with both remora-trnk.php5stage.mozilla.com _and_ preview.addons.mozilla.org.
Status: RESOLVED → VERIFIED
Keywords: push-needed
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.