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

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.

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!

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.

> 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.

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 ***

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...

Setting depends to 43583

Updating QA Contact.

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.

Un-stomping, QA change, oops!

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.

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.

redirect to FTP problem... can't find the dup.

Hi dougt, welcome to necko :)

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.

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!