405651 - Using "Download Link Target..." fails much of the time when D/Ling large files over https

Status: RESOLVED DUPLICATE of bug 309879

(Camino Graveyard :: Downloading, defect)

Description

[Chris]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.10pre) Gecko/20071127 Camino/1.6a1pre (like Firefox/2.0.0.10pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.10pre) Gecko/20071127 Camino/1.6a1pre (like Firefox/2.0.0.10pre)

On sites that use SSL, I've often experienced failures when trying to download multi-megabyte files by using the "Download Link Target..." option in the link context menu.  The site I first experienced this on was https://secure.members.easynews.com, but you'd need an account there to test that out.  So, I've set up an example on my webspace at the URL provided:  https://ssl.cs.dartmouth.edu/~cmasone.  

Reproducible: Always

Steps to Reproduce:
1. go to https://ssl.cs.dartmouth.edu/~cmasone
2. Ctrl-click on the link called "LetMe_072506.aif" 
3. select "Download Link Target..."
Actual Results:  
A dialog stating:

"The download failed. Check your network connectivity and the download folder, and try again." 

It's failed every time I've tried it.  Firefox works with the same download folder over the same network.  Small files work fine.


Expected Results:  
The file should download.

Doing the same for a small file (allinfo.php) works fine.


On easynews, every now and again D/Ling a large file would succeed, but there seemed to be no rhyme or reason to working vs failure.

Comment 1

[Chris Lawson (gone)]

This is almost certainly another symptom of bug 309879, probably due to the fact that Camino doesn't cache SSL content by default. (Neither does Firefox, but it uses different downloading code that doesn't hit that bug.)

What happens if you go into about:config and set browser.cache.disk_cache_ssl to true and try it again? I'm not recommending this as a long-term solution, but it might help as a temporary workaround.

For the record, I can't get to that site at all due to the netError.xml bustage after the landing of bug 369814. Gecko doesn't like the security certificate you're using for the testcase.

Do you see the problem at all on non-HTTPS sites?

Comment 2

[Chris]

>> Gecko doesn't like the security certificate you're using for the testcase.

I know...I was going to file another bug for "can't trust new certificate authorities," but I saw that it was already filed.  My nightly (1.6a1pre) still allows me to get to the site, though, after a cert warning.  Is there newer stuff I should be testing with?

>> Do you see the problem at all on non-HTTPS sites?

I don't, no.

Comment 3

[Chris Lawson (gone)]

Well, I was using a trunk nightly, but until the netError stuff is un-busted, that obviously won't be able to add an exception either. The latest Minefield nightly allows me through, so I think those issues are adequately covered in the other bug (I assume you meant bug 383988).

Comment 4

[Chris]

Yes, I did mean that bug.

I tried enabling caching for ssl content, and that allowed the download to proceed without trouble.  So, it looks like you're right that it's related to bug 309879.