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

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.

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.

moving to browser product

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

targeting m7

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. ;-)

mass moving m14 bugs to m15

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

qa to elig for now

Milestone 0.8 has beend released. We should either resolve this bug or update its milestone.

*** Bug 15229 has been marked as a duplicate of this bug. ***

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.

nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)

Setting target milestone to 0.9.2 (check it in anytime, even before, when the tree is open for). Per PDT triage.

Open Networking bugs, qa=tever -> qa to me.

Moving to 0.9.3.

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)

steve: is there any possible use for this feature by Composer, or is this purely a form-submit situation?

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.

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

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

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?

Updating OS to OSX, assuming this still is valid. (Have Mozilla ever been suported on Mac OS 7.5?)

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.

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.

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.

s/ENCODING/ENCTYPE in comment 28, please. Sigh.

WONTFIX per previous comments.