Loic Reporter
	Description • 8 years ago

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

	Masatoshi Kimura [:emk]
	Comment 1 • 8 years ago

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.

	Loic Reporter
	Comment 2 • 8 years ago

Maybe a misconfiguration of BMO. Landfill doesn'h have the issue.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 8 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 8 years ago

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.

	Dylan Hardison [:dylan] (he/him) Assignee
	Comment 5 • 8 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 8 years ago

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

	Dylan Hardison [:dylan] (he/him) Assignee
	Comment 7 • 8 years ago

Alright, that's not the case. I think this is fixed upstream.

	Dylan Hardison [:dylan] (he/him) Assignee
	Comment 8 • 8 years ago

Possibly a result of bug 1276820

	Dylan Hardison [:dylan] (he/him) Assignee
	Comment 9 • 8 years ago

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)

	Loic Reporter
	Comment 11 • 8 years ago

Removing NI.

	David Lawrence [:dkl]
	Comment 12 • 8 years ago

Comment on attachment 8770285 [details] [diff] [review]
1285835_1.patch

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

Looks good and fixes issue. r=dkl

	Dylan Hardison [:dylan] (he/him) Assignee
	Comment 13 • 8 years ago

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