184932 - Content-base and Content-location have line feeds, breaking images in Apple's Mail.app

Status: NEW

(MailNews Core :: MIME, defect)

Description

[benc]

I've noticed that a lot of internal mail sent around w/ inline images doesn't
display when I use the built-in Mac OS X mail program (Mail.app).

After looking at a lot of examples, I think I found the common thread, the
messages are all composed in Mozilla/Netscape, and they all have Content-base
and Content-locations with long URLs, broken over several lines.

I'm going to try to create and post a nice clean example, but if someone could
tell me if that is legal, that would be helpful. I know that header lines (like
Received:) can be broken, but I know every little about the technical aspets of
MIME.

Comment 1

[David Nesting]

It's legal to break up long headers into multiple lines, so long as the
subsequent lines all start with at least one piece of whitespace.  This may
still invalidate these header values, though.  I'm not sure if the act of
"unsplitting" these lines removes whitespace entirely or if it keeps some. 
Whitespace in URI's is bad.

It might help to see the actual headers.

Comment 2

[benc]

Content-Base: "http://<FQDN>/users/xx
	mk/publish/vendorfairedec101.html"
Content-Location: "http://<FQDN>/users/xx
	mk/publish/vendorfairedec101.html"

Whitespace in URL's is actually supposed to be accepted, and automatically
stripped, although this has not always worked well in Mozilla/browser.

Seth asked me to send the actual message to him, so I've done so. 

Comment 3

[benc]

I started hacking on some sample files today, and was wondering if someone could
provide a definition for what is legal and illegal whitespace. I noticed that
gluing ("J") the lins in VI still meant I had to strip some characters to make
the URL one continuous string.

Comment 4

[Hixie (not reading bugmail)]

->default

Comment 5

[Mike Cowperthwaite]

I just noticed this today.  It seems to happen when the URL exceeds 38 
characters.  Also, it doesn't render correctly when the attachment is opened in 
the Mozilla browser.  I was surprised when -- prompted by the original report in 
this bug -- I turned on Display Attachments Inline and saw the styling and 
images in the rendered webpage.

Regarding what Mozilla does when unsplitting the header: at least sometimes, it 
apparently only removes the newline, no spaces.  See bug 240924.

Similar rendering bugs from bogusly-wrapped headers: bug 229290, bug 234547.

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 8

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"