196009 - attach name is incomplete while it is in multi-line content-* header

Status: RESOLVED EXPIRED

(MailNews Core :: Attachments, defect)

Description

[Dmitry Chernyak]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Dmitry Chernyak]

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

Comment 3

[Dmitry Chernyak]

Ooh...
"name" and "filename" fields above are actually placed at the end of 
the first line of corresponding Content-* header.

Comment 4

[Steven Augart]

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.

Comment 5

[Gervase Markham [:gerv]]

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/

Comment 6

[Gervase Markham [:gerv]]

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.