Closed
Bug 937
Opened 26 years ago
Closed 16 years ago
Support MacBin encoding for FILE uploads in FORMs
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: llosa, Unassigned)
References
Details
(Keywords: platform-parity)
Hello I hope I found the right place for this bug and patch request.
Operating system MAC (ie. iMac)
Browsers ALL Netscape(3,4) (works perfectly on Mac IE4)
On a Netscape / Mac, Http uploads are destroying files with both a data fork and
resource fork. Files like a 120k simpletext application get sent up as 0K
On IE4 / Mac everything is kept in tact. I think somehow they use MacBinary to
their advantage.
I would rather have myusers use Netscape. How do we go about getting a patch.
I have researched this extensively with no luck, (except learning it is a
Netscape error)
Thanks
Frank LLosa
Updated•26 years ago
|
Severity: critical → enhancement
Status: NEW → ASSIGNED
Comment 1•26 years ago
|
||
Changed to an enhancment request as the release notes specifically state that
MacBinary encoding is not performed for file uploads.
As of Communicator/Navigator 4.04 the following syntax is supported to specify a
file should be transferred in MB format from a form submit page:
INPUT TYPE="FILE" enctype="MACBINARY"
If this does not address your needs please provide more details.
Updated•26 years ago
|
Summary: Http Uploads fork splitting, not on IE4 → Request: Allow user to select MacBin encoding for uploads
Comment 2•26 years ago
|
||
Changing summary to to indicate this is an enhancment request
Getting off Platform:xx type of component. These type of components being
retired due to platform info in that field.
Updated•26 years ago
|
Component: Windows FE → Networking Library
Product: MozillaClassic → Browser
Comment 4•26 years ago
|
||
moving to browser product
Comment 5•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
Target Milestone: M7
Comment 6•26 years ago
|
||
targeting m7
Summary: Request: Allow user to select MacBin encoding for uploads → [PP]Request: Allow user to select MacBin encoding for uploads
Updated•26 years ago
|
Target Milestone: M7 → M10
Comment 7•26 years ago
|
||
not going to make M7, moving to M10
Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.
Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change. If this happens, I will fix. ;-)
Updated•26 years ago
|
Target Milestone: M10 → M11
Updated•26 years ago
|
Target Milestone: M11 → M14
Comment 9•25 years ago
|
||
mass moving m14 bugs to m15
Comment 10•25 years ago
|
||
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Updated•25 years ago
|
Summary: [PP]Request: Allow user to select MacBin encoding for uploads → Request: Allow user to select MacBin encoding for uploads
Updated•25 years ago
|
Target Milestone: M15 → M17
Updated•24 years ago
|
QA Contact: elig → tever
Comment 12•24 years ago
|
||
Milestone 0.8 has beend released. We should either resolve this bug or update
its milestone.
Comment 13•24 years ago
|
||
*** Bug 15229 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
Rather than using the enctype parameter from 4.x my plan is to just use Internet
Config to determine if the resource fork of the file is significant and do the MB
encode if so. I believe IE uses this logic.
Severity: enhancement → normal
Priority: P4 → P2
Summary: Request: Allow user to select MacBin encoding for uploads → Support MacBin encoding for FILE uploads in FORMs
Target Milestone: M17 → mozilla0.9.1
Comment 15•24 years ago
|
||
nominating for dogfood (from sdagley's list of bugs that are good candidates for
our next release)
Keywords: nsdogfood
Comment 16•24 years ago
|
||
Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla1.0
Comment 19•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 20•23 years ago
|
||
steve: is there any possible use for this feature by Composer, or is this purely
a form-submit situation?
Comment 21•23 years ago
|
||
Steve: I don't know if you assaulted this before, but it should be a ton easier
now. It's designed for adding new encodings (I just did one that is awaiting
review, text/plain). Please *allow* an enctype to be specified.
Component: Networking → Form Submission
Comment 22•23 years ago
|
||
This was pretty specific to FORM submission but it could be extended to anything
that uploads a file on the Mac where it'd be important to conserve a
multi-forked file. I don't think this would apply to Composer as it is intended
to deal with cross platform single forked files
Comment 23•22 years ago
|
||
Well it certainly didn't go into Mozilla 1.0.1 and it's not clear it'll ever get
added so setting to that nebulous FUTURE milestone
Target Milestone: mozilla1.0.1 → Future
Comment 24•22 years ago
|
||
Should Mozilla not detect the presence of a resource fork and submit the file as
AppleSingle or AppleDouble without having to specify a Mac-specific ENCTYPE?
Comment 25•22 years ago
|
||
Updating OS to OSX, assuming this still is valid. (Have Mozilla ever been
suported on Mac OS 7.5?)
OS: Mac System 7.5 → MacOS X
Comment 26•22 years ago
|
||
To answer Greg, no, automatic MacBin encoding on presence of a resource fork
would be bad. You don't want a MacBin upload of a JPEG file just because you
have a preview icon in the file's resource fork. See comment #14 re: using
Internet Config to determine if a file's resource fork is significant. Not that
I know if the OS X implementation of IC gets that right since Apple seems intent
on deprecating IC
As for Torbin's question re: current validity, given Apple's intended
deprecation of resource forks in OS X I wouldn't be opposed to a WONTFIX resolution.
Comment 27•22 years ago
|
||
Technically this probably applies to Windows using NTFS as well, since NTFS
supports file streams (similar to resource forks) and we lose them on upload too.
Comment 28•22 years ago
|
||
The underlying problem is solved using .sit or .zip files when the
resource fork or file stream needs to be preserved. The original
reporter was apparently trying to upload Mac applications.
The means of using WinZip and Stuffit files are widely understood
these days. Almost all upload form CGIs aren't expecting
MacBinary, so a solution that tries to figure out when to send them
without taking the ENCODING cue from the server will make
incompatibilities arise on the Mac platform.
I second the suggestion for WONTFIX.
Comment 29•22 years ago
|
||
s/ENCODING/ENCTYPE in comment 28, please. Sigh.
Updated•16 years ago
|
Assignee: sdagley → nobody
QA Contact: benc → form-submission
Whiteboard: [wontfix?]
Updated•16 years ago
|
Flags: wanted1.9.2?
Comment 30•16 years ago
|
||
WONTFIX per previous comments.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Whiteboard: [wontfix?]
Updated•16 years ago
|
Flags: wanted1.9.2?
Priority: P2 → --
Target Milestone: Future → ---
Assignee | ||
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
•