Closed Bug 1285835 Opened 4 years ago Closed 4 years ago

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

Categories

(bugzilla.mozilla.org :: General, defect)

Production
x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: epinal99-bugzilla2, Assigned: dylan)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

Attached image filename-title.png
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
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 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.
Component: DOM → General
Product: Core → bugzilla.mozilla.org
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 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
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]
1285835_1.patch

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

Looks good and fixes issue. r=dkl
Attachment #8770285 - Flags: review?(dkl) → review+
To git@github.com:mozilla-bteam/bmo.git
   876f5eb..1497693  master -> master
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.