the docloader continues to receive data even though we've retargeted a url load to the unknown content-type dialog. We need to either come up with a new way to retarget (optimal and will likely fallout of webshell redesign), or cancel the initial load and have the save as dialog restart it. I'll soon be checking in the latter and I consider it a workaround. However, this won't be fixed until bill laws changes make it in as well.

FTP is now cancelable (code checked in 11/12/99 4:30pm pac time). passing onto bill law for his save as dialog changes.

This is still a problem in some situations (observed on Linux and Win98, I also can cause it on my NT box when downloading from the ftp server on the same machine). The problem is in ftp and/or file transport code so I'm changing the component back. Warren, Gagan, and Judson are better-qualified to handle this.

Putting on PDT+ radar.

isn't this more of a part of the URL dispatching issue than the webshell design? Handing to warren since I'll be away for a while...

I'm going to let the bug gods work this one out (WRT the PDT field). This bug is a meta bug for the two that it depends on; maybe it should go away, maybe it should stay.

Once my OpenInputStream changes (the two bug this one depends on) are in. I'll be modifying the save as code to use OpenInputStream().

I've got the stream transfer component (the save as dialog piece that does the actual download) using OpenInputStream (in my tree). It's working great so far, I'm downloading everything like a banshee. No progress notifications yet. That's next.

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

getting code review from bill law.

fix checked in 11/30/99 2:16pm pac time. We're downloading files to disk like a banshee now! HTTP's save as dialog progress meter does not give relative progress now though (see 20360).

Verified working on NT build 1999120113

I tried the latest nightly build ( Dec 6th). I am still having problems downloading. This time the dialog box says that the file type is unrecognised by netscape and if I click OK what gets downloaded is a file with a .cgi extension. I see in your comments that you verified this with the Dec 1st build. Isn't it supposed work with today's build ?

this is a file extension mapping prob. assigning to law.

what platform were are you running? removing dogfood/pdt+ status.

What URL produced the file with the .cgi extension? It must have been a cgi script. Our code isn't quite smart enough to override the apparent "extension" in the url with one based on the mime type. But that shortcoming certainly isn't PDT+ (and shouldn't be tracked with this bug, which it has nothing whatsoever to do with, aside from being tangentially related by way of "file download"). So I'm moving to M13. When I actually get to it, I'll probably close this one. There's another bug (I think) regarding getting the extension "right."

Clearing FIXED resolution due to reopen.

I tried to download the BDK tool kit 1.1 toolkit from http://www.java.sun.com/beans/software/bdk_download.html. What I am supposed to download is an executable while what gets downloaded by mozilla is download.cgi. I tried this on NT with Dec 6th nightly build. I tried to download a tar file from www.mozilla.org, that worked.

the extension bug is bug 13784 not this bug. This bug should be closed.

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

Worry about this in M15.

I think this works now. Can someone verify for us?

I am still having problems with downloading. I am using the latest nightly build ( 02-14-00 ) on NT. I went to java.sun.com/beans site and followed the steps to download BDK1.1. I clicked on the FTP download abd double clicked on the executable that was downloaded.I got this error message. " bdk1_1-win.exe is not a valid Windows NT application". I am not sure if fixing 13784 would fix this problem.

There are a few of issues mixed in here ... 1) having trouble downloading files > 1Mb . - this is working fine, I just downloaded the bdk1_1-win.exe file about a dozen times. It is 2,452KB in size. 2) file extension mapping problem ... file is coming across as .cgi - not happening for me - always .exe, an installanywhere program. So I think this is working now. 3) the file is failing to load and showing the 'bdk1_1-win.exe is not a valid Windows NT application" message. - this sounds like your file has been corrupted somehow. I am not seeing this after doing quite a few test downloads. I am going to close this for now but if you (jayashri that is) still see it, please open a new bug with a more detailed description on how we can reproduce. thx.

NT 2000022308