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)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: mikecapp, Assigned: pollmann)

References

(
URL
)

Details

Attachments

(1 file)

Patch to layout/html/forms/src/nsFormFrame.cpp to return the proper content-type
(deleted), patch
Details | Diff | Splinter Review
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.
worksforme linux build 2000-11-19-21 with a perl CGI script using the CGI module on the server end.
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?
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"
Adding some keywords
Keywords: patch, review
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
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"
sr=buster
checked in, thanks Boris
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
*** Bug 59411 has been marked as a duplicate of this bug. ***
Verifying on RedHat Linux 6.2 build 2001-01-26-15-MTEST
Status: RESOLVED → VERIFIED
Wait a sec, It is still still submitting Content-Type: unknown My bad, reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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?
reassigning
Assignee: rods → pollmann
Status: REOPENED → NEW
Vladimire, can you retest and attach the testcase you used if this is still failing? Thanks!
Status: NEW → ASSIGNED
Target Milestone: --- → Future
vladimire, any luck with that testcase?
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
verifying
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

Creator:
Created:
Updated:
Size: