- downloading a zip file does not correctly capture the name of the zip file



Tech Evangelism Graveyard
English US
17 years ago
3 years ago


(Reporter: geetha.vaidyanaathan, Assigned: Arun Ranganathan)



(Whiteboard: aok, URL)



17 years ago
Running NS6.0A on SUn Solaris 2.7
Installed NS6.0a from SUN SVR4 pkg


   Scroll to the bottom of the page
  Click on either "HTTP" or "FTP" to the right of 108773-07.
  Opt to download the file to your current working directory.
  Netscape 6 downloads the file as "".  It should download a
file, like Netscape 4.76 does.

The workaround I did was to save the file as a .zip file and then unzip the
file. Everything was OK

Comment 1

17 years ago
Adding margaret to the cc list
That server name does not exist... Is it behind a firewall?

Also, can you reproduce this problem with a recent Mozilla build?

Comment 3

17 years ago
yes iirc it's an internal server.

but it doesn't matter, this bug is a dupe of us not recognizing the suggested 
filename http parameter.
Keywords: qawanted
Whiteboard: DUPEME

Comment 4

17 years ago
bug 71118 indicates that we do support that field, please test w/ a mozilla 

Comment 5

17 years ago

*** This bug has been marked as a duplicate of 67292 ***
Last Resolved: 17 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
Whiteboard: DUPEME

Comment 6

17 years ago
Verified dup.

Comment 7

17 years ago
The problem still exists even on April 30's trunk build.(instead of naming the
patch file after the patch number, i.e.,, the file is named
""). In the meantime, bug 67292, to which this bug was a
duplicate, has already been closed. Bug 67292 seems to be a different problem
(instead of the naming of the file, the bug was about the open/save dialog
window). Anyway, since the problem still exists, (as matter of fact, I just got
another user reported the same problem today to netscape6_feedback group) I am
reopening this bug.
Resolution: DUPLICATE → ---

Comment 8

17 years ago
updating component, (I guess we do need that new file download/helper
app/mimetype component)
Assignee: asa → blakeross
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
Joe Chou, since you have access to this server, could you please attach the HTTP
response it returns?  Making progress on this bug is very difficult unless we
know what we are dealing with.

Comment 10

17 years ago
I don't have the access to the server, but I do think this should be fix by the
SunSolve folks in charge of the site.
Can someone with access to the server (someone who can download things from it) 
please run a wget -s on the URL that we're trying to fetch?  This should show 
all the headers.  Please attach the file that wget generates to this bug so we 
can see what sort of headers the server is returning....

Comment 12

17 years ago
Assignee: blake → bclary
Component: XP Apps: GUI Features → Evangelism
Ever confirmed: true
QA Contact: sairuh → zach

Comment 13

17 years ago
->Arun, can you test this using Elwood?
Assignee: bclary → aruner

Comment 14

16 years ago
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified

Comment 15

16 years ago
aok, though is this a bug?
URL: aok

Comment 16

16 years ago
aok from url->status whiteboard
URL: aok
Whiteboard: aok

Comment 17

16 years ago
yes.. it looks like this.. no "attachment" in Content-Disposition seems to be the

sunsolve spits up the following http header

Content-Disposition: filename=""
I changed our parsing of content-disposition to be more lenient a few weeks back.
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 19

16 years ago
Cannot verify, not in firewall.
Summary: In NS6 Downloading a zip file does not correctly capture the name of the zip filee → - downloading a zip file does not correctly capture the name of the zip file
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.