Closed Bug 38898 Opened 25 years ago Closed 25 years ago

HTTP donwload via CGI script downloads an HTML page instead of the real program file (e.g. JRE1.3.exe)

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 22861

People

(Reporter: momoi, Assigned: don)

References

(
URL
)

Details

** Observed with 5/10/2000 Win32 build ** This problem was initially reported by a Japanese NSPR1 user. But this problem still occurds with 5/10/2000 Win32 build. 1. Go to the above site. The choose to download Internationalized version of JRE 1.3. 2. On the next page, "accept" the license terms. 3. On the next page, choose "Download" from java.sun.com and click on "HTTP download" button. 4. Insetad of "j2re1_3_0-win-i.exe" file, you're offered to download "Download3" file, which seems to be a parent page to the form downloading page. Additional info: There is an option to download the file vi FTP protocol also from the same sun.java.com site. This option works OK.
Corrected the summary line. I don't know if this is a generic failure of HHTP file downloding procedure or particular to this site. We should investigate more. If it is a general failure, we probably should nominate this for nsbeta2.
Summary: HTTP donwload via CGI script downloads the CGI script instead of JRE1.3i → HTTP donwload via CGI script downloads an HTML page instead of the real program file (e.g. JRE1.3.exe)
The problem of "HTTP downloading" does not occur with Communicator 4.7x. and I was able to download the JRE file with it.
This bug is re-appeared by a simple CGI like below. I tested BuildID:200051012 and NS6PR1. ---------------------- #!/usr/local/bin/perl if( $ENV{'REQUEST_METHOD'} ne "POST" ) { # here is for first load print "Content-type: text/html\n\n" ; print"<html><body><FORM ACTION=/download/download3 METHOD=POST><INPUT TYPE=SUBMIT NAME=protocol VALUE=\"HTTP download\"></FORM></body></html>\n\n"; } else { # here is for second load print "Content-disposition: attachment; filename=j2sdk1_3_0-win.exe\n" ; print "Content-type: application/octet-stream; name=j2sdk1_3_0-win.exe\n\n" ; print "dummy\n"; }
lacked information: A simple CGI's name is download3. It outputs html document calls itself by 1st load.
->ruslan
Assignee: gagan → ruslan
What does this have to do with necko? I think the problem is up in the browser on how it's interpreting the content?
Actually the problem is that somebody doesn't handle Content-Dispostion header upstream correctly. Reassigning back to browser
Assignee: ruslan → momoi
Juraj, this is the issue I was talking to you about. Please look into the Content-Disposition header issue. We need to know precisely what we are outputting to the server and decide on the best course of action.
Assignee: momoi → jbetak
Status: NEW → ASSIGNED
Ignore my 2 previous comments -- I confused this one with another one,which has to do with form file uploading.
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
1. momoi is our qa engineer, please do not reassign bug to him. 2. This is either a browser url dispatching issue or necko issue. Reassing to don.
Assignee: ftang → don
don and momoi-san, this will be fixed by bug 22861's patches. So, please dup of bug 22861.
Yes, this seems like a duplicate of Bug 22861, particularly the part that has to do with URI loader & handling Content-Disposition header correctly. I'm going to resolve this bug as a duplicate but suggest that we don't verify it until Bug 22861 is fixed. Then we should try the test case suggested here. Let me mark the dependency on Bug 22861 also. *** This bug has been marked as a duplicate of 22861 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Depends on: 22861
Resolution: --- → DUPLICATE
verified DUP
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.