Closed Bug 8209 Opened 25 years ago Closed 23 years ago

ENCTYPE=multipart file upload does not work

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: ftang, Assigned: pollmann)

References

()

Details

(Whiteboard: [TESTCASE] file upload data not submitted correctly)

Attachments

(5 files)

Somehow the form submission w/ multipart does not work. Which mean we cannot do file upload. Try the form and cgi script.
Blocks: 7973
also we have the local copy of that in http://cgi-lib.stanford.edu/cgi-lib/ex/perl5/fup.html (w/ perl script of cgi)
Blocks: 7228
Bug #7973 was "fixed" in M7, but is dependent upon this to work.
If you don't have another test page, try the one we set up at: http://publish.aps.org/esub/apstest/test.html It handles a single file upload test case using Lincoln Stein's CGI.pm perl module to process the result. Works for us since Netscape 2.x (but not even now for MSIE 4.5 on the Mac - some MSIE's work). -- Arthur Smith (apsmith@aps.org)
Whiteboard: [MAKINGTEST] christian@wenz.org
Attached file file upload form
Whiteboard: [MAKINGTEST] christian@wenz.org → [TESTCASE] file upload data not submitted correctly
Overview Description: form file upload feature does not work Steps to reproduce: install a cgi-script capable of handling file uploads or use the page at http://publish.aps.org/esub/apstest/test.html; enter the filename of a local file in the textbox and click on "submit this file" Actual Results: nothing happens, to response from the server Expected Results: the server to print out a new page, showing the contents of the uploaded file Build Date & Platform: occurs M7 and current daily build (Win32) does not occur on IE3+ and NN3+ (Win32) [there, the server does respond] Additional information: dind't touch the html file from http://publish.aps.org/esub/apstest/test.html, is it cannot be simplified further. The file data does not seem to be submitted correctly (maybe no correct MIME encoding / MIME separators?), making the script go nuts. There is no entry in the server logs when calling the script from M7.
It appears in pages that has multiple form tags on it - see www.myevents.com - try uploading a file.
Isn't this dogfood because we cannot create bugzilla attachments without this?
Status: NEW → ASSIGNED
Target Milestone: M14 → M12
Bumping up priority.
Depends on: 13997
Need to fix the crash first, of course :)
Just checked in a fix. To verify, try to attach a file to this bug using apprunner. If it works, the bug is fixed. Note that, at least on Linux, you must select a file from the current directory. This is being worked on - see bug 15317
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Just checked in a fix. To verify, try to attach a file to this bug using apprunner. If it works, the bug is fixed. Note that, at least on Linux, you must select a file from the current directory. This is being worked on - see bug 15317
I'm currently trying to upload a file using the 1999101808 build under NT... it's been 'Transferring data' for about ten minutes so far (and that file ain't that huge). I'll update if/when the upload finishes...
OK, I've been trying all morning to upload a file to bugzilla using the 1999101808 build on NT. Is something else broken, is this bug not fixed... anyone have an idea? Thanks!
Checking this out...
Blocks: 16950
Status: RESOLVED → REOPENED
This looks like it was caused by some changes recently made to Necko's http library. The form upload data is no longer getting written at all. Rick, is this something you are aware of? There is a test case in this bug. Another is at http://blueviper/forms/multipart2.html. Using this testcase, and a simple server, I observed this data being posted: pollmann blueviper(43):~> echoserver.prompt Listening for clients on port 8000. --------Got a new client. POST /echo.cgi HTTP/1.0 host: blueviper:8000 accept: */* user-agent: Mozilla/5.0 [en-US] (Linux; I) referer: http://blueviper/forms/multipart2.html --------Client hung up, responding. --------Done. But at the same time, the form post data file is correct and exists in /tmp. This seems to be related to some recent changes you've made breaking apart and improving nsHTTPRequest::Build, and the error seems centered around nsHTTPRequest::OnStopRequest where the post data stream is asynchronously written to the server. Any ideas? Do you want this bug?
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Changes to fix this problem have been checked in, still working on getting this.
Blocks: 17907
After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.
QA Contact update.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Whatever changes had happened to break my fix seem to have reversed. It works for me now, so I'm marking it fixed. Cool. :)
Doesn't work on: - MacOS86 2000-02-01-09 Commercial build Can't upload file...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Still broken for MacOS86 2000-02-08-17 mozilla build. Tested against Win32 and Linux builds of same date and they work fine. Used the http://publish.aps.org/esub/apstest/test.html link.
Target Milestone: M13 → M15
Does not work on Win32 2000021608 build on Windows 98. Used this testcase: http://publish.aps.org/esub/apstest/test.html I also tried it with a file-submission form on a private site of mine, and it didn't work, either. The application churns but nothing else happens (the form never seems to be submitted)
I just tested at: http://publish.aps.org/esub/apstest/test.html And posting worked fine for me. Re-closing. If you are still having problems, please Reopen and give details such as platform, size of file, file nemae, ... Note also that it may take a long time for larger files to upload to the server. Thanks!
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Marking VERIFIED FIXED on: - MacOS9 2000-05-02-08-M15 Commercial - Linux6 2000-05-02-08-M15 Commercial - Win98 2000-05-02-08-M15 Commercial
Status: RESOLVED → VERIFIED
No longer blocks: 17907
It still doesn't work, if the file doesn't exits (or if the empty filename is specified). Here is a cgi-script to reproduce it: put it into a cgi-bin directory, then go to cgi-bin/env?form This will show a form with a "file" input and a "submit" button. If you just push "submit" - it will never never return... If you enter a valid (existing) path into the input field and submit again, you'll see a print out of the environment and the content of the file... This is especially bad because there is no way to check whether the file exists on the client side :-( #!/bin/csh -f if ($?QUERY_STRING) then if ("$QUERY_STRING" == "form") then cat <<EOF Content-type: text/html;" <html> <body> <form action=env method=post enctype="multipart/form-data"> <input type=file name=file><br> <input type=submit name=sub value="Submit"> </form> </html> EOF exit endif endif echo "Content-type: text/plain" echo "" echo "" echo "**** COMMAND: $0 ****" env if ("$REQUEST_METHOD" == "POST") then echo $CONTENT_LENGTH head -c $CONTENT_LENGTH endif
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Works fine. Please use a recent nightly build and test it again. If you are using 0.9.7, see bug 116210.
Status: REOPENED → RESOLVED
Closed: 25 years ago23 years ago
Resolution: --- → FIXED
QA Contact: ckritzer → bsharma
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: