Open Bug 229075 Opened 16 years ago Updated 4 years ago

`Content-Disposition: inline' is treated as an attachment, if also a filename is given.

Categories

(MailNews Core :: MIME, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: carsten, Assigned: philbaseless-firefox)

References

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

A part of a MIME message (possibly the whole message) described by

Content-Disposition: inline; filename="foo"

is treated as an attachment.  Without filename, everything is ok.


Reproducible: Always

Steps to Reproduce:
The part with filename `error' should be displayed inline.
I don't think it's a real error, see RFC 2183
<http://www.faqs.org/rfcs/rfc2183.html>, paragraph 2.3 ... But I can understand
that you want to give priority to the 'inline' setting.
Hi Jo, thanks for your comment, it made me take a closer look at RFC 2183.  It
says there:

[...] the [filename] parameter may be used on any MIME entity, even `inline'
ones. These will not normally be written to files, but the parameter could be
used to provide a filename if the receiving user should choose to write the part
to a file.

I think this is the desired behaviour.  Differing bevaviour is of course not a
bug, but I see it as a misfeature :-)

BTW, I would not have brought this up if I could tell Mutt not to send a
filename parameter.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
From comment 0:
> A part of a MIME message (possibly the whole message) described by
>    Content-Disposition: inline; filename="foo"
> is treated as an attachment.  Without filename, everything is ok.

This *is* true for the message body; bug 182627.


Using Mozilla 1.7b-0406, Win2K, the display of the attached message differs 
slightly from the report:  If  View|Display Attachments Inline  is set, all four 
parts of the message are displayed.  If it is not set, only the first two 
(unnamed) parts are displayed.

Either way, three parts are shown in the attachment panel: "Part 1.2" "ok" and 
"error".

See bug 147461.
This attachment expands on the original from Carter.  There are two messages in
this mbox; the first is like Carter's except it provides an initial plain-text
message body, then the four text/html attachments.  The second message is
similar, except that the four attachments are image/gif instead.

With Display Attachments Inline set, both messages display all four parts. 
With Display Attachments Inline turned off, the two *unnamed* text/html parts
are still displayed, whereas all four of the image/gif parts are hidden.

Carter, any comment?  I'm not sure your original reported bug still exists, at
least not in the form you attached it.
(In reply to comment #4 and #5)

Hi Mike,

since I do not see any Carter around, I will answer :-)

Thanks for finding the connection with the other reported bug and for mentioning
the importance of the presence of a file name there.

I cannot comment on 1.7, with 1.6 the behaviour seems to be exactly the same as
with 1.5.

I had not tried switching on `view attachments inline'.  I do think that the
situation is clear though:  The distinction between an attchment and inline data
should be made depending on whether the Content-disposition value is
`attachment' or `inline', not depending on the presence of a filename.  Indeed
the presence of a filename should not make a difference when displaying, it is
just a hint of what name to use when saving the part to disk.

Greetings,

Carsten
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → mime
Product: Core → MailNews Core
No longer depends on: 182627
Assignee: nobody → philbaseless-firefox
with patch to Bug 551698, problem email with fetch by part on and view attmnts inline off.

Really not sure if inline means to always be inline or if that is our expectation or what. Anyone up to speed on this bug might look and see if this is ok and now a dupe.
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
name="=?KOI8-R?Q?=E2=C1=CC=C1=CE=D3_=EF=EF=EF_=EE=C1=D5=CB=C1-=F3=D7=D1=DA=D8?=
=?KOI8-R?Q?_=28=CD=C1=D4=C5=D2=C9=C1=CC=D9_=CB_=D3=CF=D7=C5=D4=D5_?=
=?KOI8-R?Q?=C4=C9=D2=C5=CB=D4=CF=D2=CF=D7=29=2Exlsx?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=KOI8-R''%E2%C1%CC%C1%CE%D3%20%EF%EF%EF%20%EE%C1%D5%CB%C1%2D%F3;
filename*1*=%D7%D1%DA%D8%20%28%CD%C1%D4%C5%D2%C9%C1%CC%D9%20%CB%20%D3%CF;
filename*2*=%D7%C5%D4%D5%20%C4%C9%D2%C5%CB%D4%CF%D2%CF%D7%29%2E%78%6C%73;
filename*3*=%78

should be so

Content-Transfer-Encoding: base64
Content-Disposition: attachment;
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
name="=?KOI8-R?Q?=E2=C1=CC=C1=CE=D3_=EF=EF=EF_=EE=C1=D5=CB=C1-=F3=D7=D1=DA=D8?=
=?KOI8-R?Q?_=28=CD=C1=D4=C5=D2=C9=C1=CC=D9_=CB_=D3=CF=D7=C5=D4=D5_?=
=?KOI8-R?Q?=C4=C9=D2=C5=CB=D4=CF=D2=CF=D7=29=2Exlsx?="
filename*0*=KOI8-R''%E2%C1%CC%C1%CE%D3%20%EF%EF%EF%20%EE%C1%D5%CB%C1%2D%F3;
filename*1*=%D7%D1%DA%D8%20%28%CD%C1%D4%C5%D2%C9%C1%CC%D9%20%CB%20%D3%CF;
filename*2*=%D7%C5%D4%D5%20%C4%C9%D2%C5%CB%D4%CF%D2%CF%D7%29%2E%78%6C%73;
filename*3*=%78
You need to log in before you can comment on or make changes to this bug.