STR: Open this PNG https://bugzilla.mozilla.org/attachment.cgi?id=8769461 Result: filename on title wrongly displayed with UTF8 encoding. If I open the same PNG of a Bugzilla demo, it's fine: https://landfill.bugzilla.org/bugzilla-5.0-branch/attachment.cgi?id=5130 Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6bd2071b373f&tochange=b695d9575654 Akshendra Pratap — Bug 224209 - Correct filename on title when viewing an image from a PHP file. r=bz

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 https://tools.ietf.org/html/rfc6266 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.

It looks like someone updated Encode on one or more of the webheads...

Oh, and the landfill link at https://landfill.bugzilla.org/bugzilla-5.0-branch/attachment.cgi?id=5130 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

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)

Removing NI.

Comment on attachment 8770285 [details] [diff] [review] 1285835_1.patch Review of attachment 8770285 [details] [diff] [review]: ----------------------------------------------------------------- Looks good and fixes issue. r=dkl

To git@github.com:mozilla-bteam/bmo.git 876f5eb..1497693 master -> master