Closed Bug 1285835 Opened 4 years ago Closed 4 years ago

BMO sending bogus Content-Disposition filenames when the filename is not ASCII


( :: General, defect)

Windows 7
Not set





(Reporter: epinal99-bugzilla2, Assigned: dylan)


(Blocks 1 open bug)


(Keywords: regression)


(2 files)

Attached image filename-title.png
STR: Open this PNG 

Result: filename on title wrongly displayed with UTF8 encoding.

If I open the same PNG of a Bugzilla demo, it's fine:

Regression range:

Akshendra Pratap — Bug 224209 - Correct filename on title when viewing an image from a PHP file. r=bz
Blocks: 224209
Flags: needinfo?(akshendra521994)
Keywords: regression
Is this really a Firefox issue? When I download the attachment, the filepicker suggests
"=-UTF-8-Q-Capture=20d=E2=80=99=C3=A9cran=202016=2D07=2D10=20=C3=A0=2004-=.55.19.png" and IE and Chrome agrees with the download file name.
Maybe a misconfiguration of BMO. Landfill doesn'h have the issue.
BMO is sending this header:

Content-disposition: inline; filename="=?UTF-8?Q?Capture=20d=E2=80=99=C3=A9cran=202016=2D07=2D10=20=C3=A0=2004?=.55.19.png"; filename*=UTF-8''=?UTF-8?Q?Capture=20d=E2=80=99=C3=A9cran=202016=2D07=2D10=20=C3=A0=2004?=.55.19.png

Per spec at the "filename" param's value is defined to be ISO-8859-1.  The filename* value is encoded per RFC 5987 and can be non-ASCII.

The spec also says, section 4.3:

   Many user agent implementations predating this specification do not
   understand the "filename*" parameter.  Therefore, when both
   "filename" and "filename*" are present in a single header field
   value, recipients SHOULD pick "filename*" and ignore "filename".

But I'm pretty sure we do that.  See nsMIMEHeaderParamImpl::DoParameterInternal and the caseAResult, caseBResult, caseCDResult bits...
Oh, but we do.  It's just that the value being sent is garbage.  The spec says (RFC 5987 section 3.2.1) partway through:
   Inside the value part, characters not contained in attr-char are
   encoded into an octet sequence using the specified character set.
   That octet sequence is then percent-encoded as specified in Section
   2.1 of [RFC3986].

So the value in this case is supposed to be %-encoded UTF-8 text, but it's ... clearly not.  Instead it's encoded as quoted-printable as far as I can tell.  Totally looks like a BMO bug.
Component: DOM → General
Product: Core →
Summary: Filename on title displayed in UTF-8 encoding on BMO → BMO sending bogus Content-Disposition filenames when the filename is not ASCII
Version: 36 Branch → Production
It looks like someone updated Encode on one or more of the webheads...
Assignee: nobody → dylan
Oh, and the landfill link at sends:

Content-disposition: inline; filename="=?UTF-8?Q?Capture=20d=E2=80=99=C3=A9cran=202016=2D07=2D10=20=C3=A0=2004?=.55.19.png"

and then we take the "not RFC 6266" codepath and try RFC 2047 on the value and end up with something reasonable in this case....
Alright, that's not the case. I think this is fixed upstream.
Possibly a result of bug 1276820
Depends on: 1276820
It seems pretty easy to fix this now that I've read the RFCs. I will have a patch up soon and with any luck it will go out with a push this evening (9pm Pacific)
Attached patch 1285835_1.patchSplinter Review
Attachment #8770285 - Flags: review?(dkl)
Removing NI.
Flags: needinfo?(akshendra521994)
Blocks: 1286379
Comment on attachment 8770285 [details] [diff] [review]

Review of attachment 8770285 [details] [diff] [review]:

Looks good and fixes issue. r=dkl
Attachment #8770285 - Flags: review?(dkl) → review+
   876f5eb..1497693  master -> master
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.