Closed Bug 18725 Opened 25 years ago Closed 24 years ago

having trouble downloading files > 1Mb

Categories

(Core :: Networking, defect, P2)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: jud, Assigned: law)

References

()

Details

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.
Assignee: valeski → law
FTP is now cancelable (code checked in 11/12/99 4:30pm pac time). passing onto
bill law for his save as dialog changes.
Assignee: law → gagan
Component: Necko → Networking-Core
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.
Whiteboard: [PDT+]
Putting on PDT+ radar.
Assignee: gagan → warren
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...
Assignee: warren → valeski
Blocks: 18951
Depends on: 18435
Depends on: 18434
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.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 12/3
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.
Target Milestone: M12
*** 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).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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 ?
Status: VERIFIED → REOPENED
this is a file extension mapping prob. assigning to law.
Assignee: valeski → law
Status: REOPENED → NEW
Summary: [DOGFOOD]having trouble downloading files > 1Mb → having trouble downloading files > 1Mb
Whiteboard: [PDT+] 12/3
what platform were are you running? removing dogfood/pdt+ status.
Status: NEW → ASSIGNED
Target Milestone: M12 → M13
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."
Resolution: FIXED → ---
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.
Priority: P3 → P2
Target Milestone: M13 → 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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
NT 2000022308
Status: RESOLVED → VERIFIED
No longer blocks: 18951
You need to log in before you can comment on or make changes to this bug.