Closed
Bug 60737
Opened 24 years ago
Closed 23 years ago
[FIX]files uploaded via HTML forms have "content-type: unknown" instead of "content-type: application/octet-stream"
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: mikecapp, Assigned: pollmann)
References
()
Details
Attachments
(1 file)
Problem is with <input type="file"> widgets in an HTML form.
Form method is "post".
Form enctype is "multipart/form-data".
If the file widget is left empty, values of any subsequent widgets in the same
form are not available to the recipient of the form. (Allaire ColdFusion in our
case.) Placing the file widget as the last field in the form appears to be a
kludge workaround, though obviously this is no good with multiple file widgets.
The problem only occurs with an empty widget. Specifying a zero-length file in
the widget does not cause this problem.
Problem does not occur in any other browser tested.
Comment 1•24 years ago
|
||
worksforme linux build 2000-11-19-21 with a perl CGI script using the CGI module
on the server end.
Comment 2•24 years ago
|
||
Reporter, could you please let us know what build you are using to test this and
possibly attach a small document with a form with which you see this problem?
That would expedite the handling of this bug.
Thanks for using Mozilla and reporting bugs!
Original report was based on build 2000111704/Win32, the current mozillazine
link. I've just downloaded and installed build 2000111920/Win32 and am seeing
the same behaviour. I've also confirmed it on a colleague's 2000111621/Linux build.
Sample problem case:
<html><body>
<form action = "test.uiFormHandler.cfm"
name = "bug_mozillaFileUpload"
method = "post"
enctype = "multipart/form-data">
<input name="before" type="text" value="before_value"><br>
<input name="file" type="file"><br>
<input name="after" type="text" value="after_value"><br>
<input name="submit" type="submit">
</form>
</body></html>
If I submit this form without specifying a file, the receiving page only gets a
"before" value; the "after" value doesn't exist. As I said, we're using
ColdFusion on the backend, so in this case the variable "Form.after" is not defined.
Hmm, this is interesting...
Just been playing with this bug some more. I get the exact same problem - loss
of form field values after a file upload widget - if I DO specify a file but the
file extension is not a recognized one. In this case we lose the file field
value as well as any following ones - it's normal for an unspecified file widget
to be invisible to the receiver so I didn't mention it before.
So "test.txt", "test.doc" and "test.html" all work fine, but "", "test.prj" and
"test.xyz" all cause the same error.
Maybe a mimetype-related bug?
Comment 5•24 years ago
|
||
I tried using both Netscape 4.7 and Mozilla with the HTML you provided and not
specifying a filename in the file input. The actual POST requests sent were:
Mozilla:
-----------------------------11258981671369133069635723058
Content-Disposition: form-data; name="before"
before_value
-----------------------------11258981671369133069635723058
Content-Disposition: form-data; name="file"; filename=""
Content-Type: unknown
-----------------------------11258981671369133069635723058
Content-Disposition: form-data; name="after"
after_value
-----------------------------11258981671369133069635723058
Content-Disposition: form-data; name="submit"
-----------------------------11258981671369133069635723058--
Netscape:
-----------------------------20004719394240937231542925894
Content-Disposition: form-data; name="before"
before_value
-----------------------------20004719394240937231542925894
Content-Disposition: form-data; name="file"; filename=""
-----------------------------20004719394240937231542925894
Content-Disposition: form-data; name="after"
after_value
-----------------------------20004719394240937231542925894
Content-Disposition: form-data; name="submit"
Submit Query
-----------------------------20004719394240937231542925894--
The only difference is the "Content-Type" field Mozilla has for the file input.
That field is set to "Unknown" for any files that Mozilla does not recognize by
extension, as far as I can tell. So that would be the root of the problem.
From RFC 1867 (which covers file upload in HTML forms) we have the following
description of multipart/form-data:
Each part should be labelled with an appropriate content-type if the media
type is known (e.g., inferred from the file extension or operating system
typing information) or as application/octet-stream.
It looks like Mozilla is incorrectly labeling files it does not recognize as
"unknown" instead of "application/octet-stream". I am changing the summary on
this bug to reflect this and confirming it. OS -> All, since it happens on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Summary: form data corrupted by empty file upload widget → files uploaded via HTML forms have "content-type: unknown" instead of "content-type: application/octet-stream"
Comment 6•24 years ago
|
||
Comment 8•24 years ago
|
||
excellent investigation and trouble shooting skills Boris! I'm sending email to
Rick Potts on this one though. We *should* be doing more than using the
MIMEService to do try and determine mappings. We have a byte scanner that we
should be engaging here. That way we can be a little smarter about how to
determine the content type.
see
http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#240
Comment 9•24 years ago
|
||
I will try to get this patch in soon
Status: NEW → ASSIGNED
Summary: files uploaded via HTML forms have "content-type: unknown" instead of "content-type: application/octet-stream" → [FIX]files uploaded via HTML forms have "content-type: unknown" instead of "content-type: application/octet-stream"
Comment 10•24 years ago
|
||
sr=buster
Comment 11•24 years ago
|
||
checked in, thanks Boris
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•24 years ago
|
||
All working & wonderful; thanks guys. This was the first time I'd posted a
report to Bugzilla, and I was very, very impressed - Boris had a patch out
within HOURS of my opening the issue.
Comment 13•24 years ago
|
||
*** Bug 59411 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
Verifying on RedHat Linux 6.2 build 2001-01-26-15-MTEST
Status: RESOLVED → VERIFIED
Comment 15•24 years ago
|
||
Wait a sec, It is still still submitting Content-Type: unknown
My bad, reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 16•24 years ago
|
||
Vladimir, I'm seeing "Content-Type: application/octet-stream" here. Could you
attach the testcase you used to test this? Also, do you see the problem with a
non-Mtest build?
Assignee | ||
Comment 18•24 years ago
|
||
Vladimire, can you retest and attach the testcase you used if this is still
failing? Thanks!
Status: NEW → ASSIGNED
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 19•23 years ago
|
||
vladimire, any luck with that testcase?
Comment 20•23 years ago
|
||
bzbarsky@mit.edu This is fixed. I tested with windows 98 build
2001-05-03-04-trunk and used HttpInspector tool which you can get from
download.com.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Updated•6 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
•