Closed
Bug 85742
Opened 23 years ago
Closed 23 years ago
File upload causes server error
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: sean.schneyer, Assigned: rods)
References
()
Details
Attachments
(2 files)
I am using Build ID 2001061304 on Windows ME. Unfortunately the above link is in a password protected site. Unless you use Gelco/Direct to do company exprense reports you will not be able to access the link. I will attach the page source as a seperate attachment though. Basically, what is happening is that I am trying to upload an .xml file that contains my expense report data. I have no problems uploading the file using Netscape 4.75, however, it does not work with Mozilla. Since I don't have access to the server source I have no way of knowing what is going on at the server side. I have reported the problem to their customer service as well, just in case.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
We're going to need a little more info here... like what the error is, at least. Even that would not help all that much, most likely. As things stand, there's really nothing we can do here.
Reporter | ||
Comment 3•23 years ago
|
||
The error is a generic server error. It basically says: "The server encountered an internal error. This error was most likely caused by a server misconfiguration. Please contact the system administrator." So basically your typical Error 500 message. The only reason that this should cause an error is if the upload is handled differently in Mozilla than in Netscape 4.x (it also works fine in Internet Explorer). So you are basically saying I need to use a sniffer and determine what the differences are in the upload process? I would expect the upload to work the same in both products. What else do you need me to provide to get this fixed? Until this is fixed, I can't use Mozilla 100% of the time because I can't do my travel reports without this functionality!!!
Comment 4•23 years ago
|
||
Well, the source of the file upload form would help at the very least... What you've attached is the source of the login form. Chances are, they're using a POST form and a separate Mozilla bug is keeping you from getting the real source. :( Thanks for taking the time to help investigate this.... it helps a lot with getting it resolved.
Reporter | ||
Comment 5•23 years ago
|
||
Comment 6•23 years ago
|
||
OK. I used the form to upload a file to a test cgi that just dumps out what the data it got was. NS 4.x sends: -----------------------------4839364361335586451427600148 Content-Disposition: form-data; name="Tab" -----------------------------4839364361335586451427600148 Content-Disposition: form-data; name="Button" Upload -----------------------------4839364361335586451427600148 Content-Disposition: form-data; name="handler" reportList -----------------------------4839364361335586451427600148 Content-Disposition: form-data; name="UploadFile"; filename="foo.html" Content-Type: text/html <html> <body> <a target="_content" href="http://www.mozilla.org">Go there!</a> </body> </html> -----------------------------4839364361335586451427600148 Content-Disposition: form-data; name="AttachTo" New -----------------------------4839364361335586451427600148-- Mozilla sends: -----------------------------557606309421350439904543756 Content-Disposition: form-data; name="Tab" -----------------------------557606309421350439904543756 Content-Disposition: form-data; name="Button" Upload -----------------------------557606309421350439904543756 Content-Disposition: form-data; name="handler" reportList -----------------------------557606309421350439904543756 Content-Disposition: form-data; name="UploadFile"; filename="/home/bzbarsky/foo.html" Content-Type: text/html Content-Transfer-Encoding: binary <html> <body> <a target="_content" href="http://www.mozilla.org">Go there!</a> </body> </html> -----------------------------557606309421350439904543756 Content-Disposition: form-data; name="AttachTo" New -----------------------------557606309421350439904543756-- The only differences are: 1) The filename is different for Mozilla -- it gives the full path. This is only a difference on Unix -- on Win32 both give the full path 2) Mozilla sends a Content-Transfer-Encoding header for the file. Could the server just not be dealing well with getting a Content-Transfer-Encoding header?
Comment 7•23 years ago
|
||
Looks like PHP's parser is severely broken, leading to this bug. A fix has just been checked in. Sean, could you retest with a June 20, 2001 build once those are available? Thanks! *** This bug has been marked as a duplicate of 83065 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 8•23 years ago
|
||
Although the server I was connecting to wasn't using php, this has fixed the problem for me as well. Verified on Build 2001062204 using Windows ME.
Updated•5 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•