User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030206 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030206 While Mozilla receives message whith mime-attachment who's name in content-type/disposition header is splitted across several lines, Mozilla shows onli first part of filename. Reproducible: Always Steps to Reproduce: send attachment with following mime-part headers: ============================================================ Content-Type: application/msword; name="some long"[--end of line--] [--tab--]"file name.doc" Content-Disposition: attachment; filename=="some long"[--end of line--] [--tab--]"file name.doc" ============================================================ Actual Results: 1. In attach window filename presented as "some long", i.e. is stripped to the part from the first line of header (but extension-dependent icon presented correctly) 2. "Save As" and "Save All" right-click menu commands saves an attach with stripped filename as in (1.) (and without extension, of course). Expected Results: Full file name must be presented and saved. Such attaches are usual while some mailer wraps long quoted-printable filenames. Example is M$ Office documents in some non-english language.
Shouldn't that wrap as: Content-Disposition: attachment; filename=="some long[--end of line--] [--tab--]file name.doc" instead of inserting quotes in the middle? Because Content-Disposition: attachment; filename=="some long"[--end of line--] [--tab--]"file name.doc" is equivalent to Content-Disposition: attachment; filename=="some long" "file name.doc" no?
Yes. Sorry. I was trying to represent the bug by hands and made a mistake. The actual header was: =============================================================================== Content-Type: application/x-msexcel; name==?Windows-1251?Q?=282=29_=D2=DD=CE_=E8=ED=EA_=C8=C1_=28=D0=EE=F1=E8=ED=EA?= [tab]=?Windows-1251?Q?=E0=F1=29_=28=F0=E0=F1=F5_=E8_=E4=EE=F5_=EF=EE_=F2=E0=F0?= [tab]=?Windows-1251?Q?=E8=F4=E0=EC_=C8=C1=29=5F1=2Exls?= Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename==?Windows-1251?Q?=282=29_=D2=DD=CE_=E8=ED=EA_=C8=C1_=28=D0=EE=F1=E8=ED=EA?= [tab]=?Windows-1251?Q?=E0=F1=29_=28=F0=E0=F1=F5_=E8_=E4=EE=F5_=EF=EE_=F2=E0=F0?= [tab]=?Windows-1251?Q?=E8=F4=E0=EC_=C8=C1=29=5F1=2Exls?= =============================================================================== And mailer was: X-Mailer: The Bat! (v1.60h) So probably the problem is around the character encoding... Or probably that form is not RFC compliant? - I was lost in RFC... :-)
Ooh... "name" and "filename" fields above are actually placed at the end of the first line of corresponding Content-* header.
The syntax of these continuation lines is specified in RFC 2184, at http://www.ietf.org/rfc/rfc2184.txt, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations" I'll go over it. Dmitry (bug reporter), I would appreciate it if you could use the "Create a New Attachment" field on the page http://bugzilla.mozilla.org/show_bug.cgi?id=196009 and actually attach an email message demonstrating the problem. Maybe you could give a very short file a very long name, and attach it to the email message? That would be the best for me; I don't completely trust the in-line text.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.