Closed Bug 85742 Opened 23 years ago Closed 23 years ago

File upload causes server error

Categories

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

x86
Windows ME
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 83065

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

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.
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?
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
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.
verifying per previous coment
Status: RESOLVED → VERIFIED
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

Created:
Updated:
Size: