Closed Bug 40857 Opened 20 years ago Closed 19 years ago

won't download file, after submitting form

Categories

(Core :: Networking: FTP, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: xalkina, Assigned: dougt)

References

()

Details

(Whiteboard: [nsbeta2-])

Attachments

(1 file)

need to follow the whole procedure of registering to get to correct & working
version of page. after clicking one of the download buttons, mozilla seems to do
something and then stops.
linux-2000052520
This may ne a network problem: I had no problem obtaining the JDK
from this site with Linux 2000052708.
reassinging
Assignee: rods → pollmann
I was also able to download from this site successfully in recentl nightly 
builds.  Reporter, can you:

1) Try a more recent build - this morning's should be fine.  :)
2) Provide more details about exactly how to get to the download page that 
caused you problems.  For example, a list of each link you click on any each 
thing you type to get there, and which button you use to download (FTP vs HTTP).

Thanks!
Per an email from Christos Cheretakis <xalkina@otenet.gr>:
   Well, well. Here we go!

1. java.sun.com (in a location bar that's not working correctly, by the
way)
2. Products & APIs -previous time it was in the news in the right column
3. In the right col, java2ee 1.2.1 for linux
4. Select the one 20MB bundle, linux platform, continue
5. Say what you have to say in the license agreement. Just use the
bottom accept button to play good boy.
6. They lied. It's 10, not 20 MBs. Use ftp.
7. Mozilla seems to try to do something, but just stops.

  Actually I hoped it would work this time! Build is 2000052920, on
linux.

        C.
I think I can reproduce this bug on 2000062108.  Exactly what I see is a
download status window with the heading "Saving From:", "To:", etc but without
information attached to them.  Also, I get this Javascript error after I
selected where to save the file:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Could not convert Native argument
arg 0 [nsIStreamTransferOperation.source]"  nsresult: "0x8057000a
(NS_ERROR_XPC_BAD_CONVERT_NATIVE)"  location: "JS frame ::
chrome://global/content/downloadProgress.js :: loadDialog :: line 28"  data: no]

This probably has something to do with it.
What ever problems I had before it seems to be fixed on 2000062408 on Linux.  I
can download just fine now.
Works for me too. (Used FTP download to get the ~20Mb single Linux bundle with 
no problems.)  The received file was actually 9.8Mb (10079329 bytes)  I untarred 
it with no problems.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
ftp does not work. I get a download dialog when using the http button, but
cannot save the file. This is another bug, however.
Christos, what build are you using - can you try again with today's if it is not 
today's or yesterday's builds?  Two days ago there was a networking regression 
that made all form posts fail, and that might be what you saw.
Network regression? Huh! Nope.
Using 062808 now, still the same thing. http seems to work (but cannot save) ftp
fails.
Han, hchcheng, and I are not seeing this problem.  Can you give any more 
suggestions on how to reproduce it?  Also, can you try creating a new profile 
and trying again?  The latest build?

Things that might help:
What version of Linux you are running
Try creating a new profile and running with that
Don't uncheck the "Show me this warning in the future" button on the security
    dialog
Exact sequence of pages you clicked on to get to the download page

If nobody else can reproduce the bug, it may have to be closed out.
Tried again with 2000070710 on linux. http seems to work, although no download
window is opened. Mozilla seems to download since the progress bar changes. ftp
does not work, and on the console it says 'Error downloading <page>'. Did not
uncheck the option for the warning message when submitting forms this time.

And here's the exact sequence of pages:
1. Formated for printing version of this page
2. Follow link to Download4 page (which does not initiate download, but lets you
select what to download)
3. Selecting J2SE going to http://java.sun.com/j2se
4. Selecting older versions, going to http://java.sun.com/products/jdk/1.2/
5. Selecting download for windows which is page
http://java.sun.com/products/jdk/1.2/download-windows.html
6. Accepting license agreement
7. Selecting large file download
8. Selecting either the first ftp button or the single http
Thanks for the explicit steps, that helped a lot!

I see this now.  The HTTP download button does not open up a window asking where 
to save the file.  I see this on both Linux and NT, today's build.  On NT, after 
downloading the file, it executes it without asking for confirmation.  This 
seems like a serious security risk!
Status: RESOLVED → UNCONFIRMED
OS: Linux → All
Hardware: PC → All
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached file test case
The problem is due to a bug in how the headers of this form that come as the 
result of a link click of form submission:

Content-disposition: attachment; filename=foo.exe
Content-Type: application/octet-stream

See this nifty exploit:

http://blueviper/bugs/music.html

This bug is a huge security hole because remote, untrusted code can be 
downloaded and executed without the user's consent our awareness.  (form submit 
can be scripted)  

The problem is present for both form submit and link clicks, as demonstrated by 
the exploit, which could have been a form that was submitted via javascript as 
the page was loaded.  In this case it is just a link!  :)

I don't know if the problem is in networking, webshell, or somewhere upstream, 
but passing it off to Networking gurus for the first look.  Thanks!

The FTP link also does not work for me, which is probably a separate issue.
Assignee: pollmann → gagan
Status: ASSIGNED → NEW
Component: Form Submission → Networking
Keywords: nsbeta2
Summary: won't download file, after submitting form → Browser downloads and executes code with no warning [security hole the size of Texas ;)]
> The problem is due to a bug in how the headers of this form that come as the
> result of a link click of form submission:

Ack, bad word choice - I should have said:

The problem is a bug in how we handle the headers returned by the server after 
this form submission.  These headers are of the form:
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
Adding security guru.
CC'ing some more people that might be familiar with what happens after we load a 
URL.  If nothing else, I'm sure the exploit will be of interest to anyone 
running a recent Windows build.  ;)
This is a duplicate of Bug #43583 --> implement the helper app dialog before
launching the helper app. Back end launching of helper apps was finished before
the UI was done for prompting the dialog.

Marking as a dup.

*** This bug has been marked as a duplicate of 43583 ***
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
This bug was originally about something else!
Christos, you may be right - the bug was duped because half of the problems you 
reported are a duplicate.

Not being able to download via HTTP is a duplicate of bug 43583.
Not being able to download via FTP may be a separate issue.
When 43583 is fixed, this bug should be retested.
Per Pollman's last comments, I'm re-opening...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Setting depends to 43583
Depends on: 43583
Updating QA Contact.
QA Contact: ckritzer → tever
The http download part of this bug is fixed now (sortof, well, at least the exe 
is not executed by default).  Restoring summary, removing beta2+ because this is 
not as severe of a problem.
QA Contact: tever → ckritzer
Summary: Browser downloads and executes code with no warning [security hole the size of Texas ;)] → won't download file, after submitting form
Whiteboard: [nsbeta2+]
Un-stomping, QA change, oops!
QA Contact: ckritzer → tever
Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix 
to make a call on this bug. PDT wants to know if there is still a security risk 
and exactly what the problem is now.
Whiteboard: [NEED INFO]
The security problem has been fixed.  From what I have seen, the impact to 
the user of not fixing this bug is that clicking on a button that is supposed to 
download a file from an ftp URL does not download the file.  
Putting on [nsbeta2-] radar. Not critical to beta2. 
Whiteboard: [NEED INFO] → [nsbeta2-]
redirect to FTP problem... can't find the dup.
Assignee: gagan → rjc
Status: REOPENED → NEW
Target Milestone: --- → Future
Hi dougt, welcome to necko :)
Assignee: rjc → dougt
Blocks: 62352
Christos, I could download the package via ftp following the instructions that
ckritzer@netscape.com added on 2000-06-01 08:42.  I am marking as worksforme. 
Please reopen if you still continue to see this problem.

Status: NEW → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → WORKSFORME
reporter:

This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.

If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
 but do not verify it yet.

For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.
Seems to be working fine with 2001091408.
VERIFIED:
thanks!
Status: RESOLVED → VERIFIED
Component: Networking → Networking: FTP
You need to log in before you can comment on or make changes to this bug.