1961710 - Outlook sends `Content-Disposition: filename*=UTF-8''` and then parses it incorrectly

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[jscher2000]

When downloading an attachment from https://outlook.office.com/, Firefox reports receiving the following header (example):

content-disposition: attachment; filename*=UTF-8''Voucher%20-%20MAIKOYA.pdf

Firefox parses this to a file name of

UTF-8Voucher - MAIKOYA.pdf

when

Voucher - MAIKOYA.pdf

is expected.

MDN implies that Firefox knows how to parse this syntax. https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Content-Disposition

I tested in Firefox 137.0.2, but a user on SUMO reports that this affects Firefox 128.9.0esr as well, so unless they both had a recent change related to parsing filename* this may be an old issue. https://support.mozilla.org/questions/1507363

Note #1: I did not use whatever next level debugging tools are needed to determine whether Microsoft is sending some illegal characters.

Note #2: Copy Download Link returns a blob: URL.

Comment 4

[Tom Schuster (MoCo)]

I tried to reproduce this with the header from comment 0 and it seems to work correctly on my local HTTP server. Does anyone have a publicly available link?

Comment 5

[Tom Schuster (MoCo)]

Does this reproduce with files that are not PDFs?

Comment 6

[Alice0775 White]

(In reply to Tom Schuster (MoCo) from comment #5)

Does this reproduce with files that are not PDFs?

I can reproduce the issue with https://outlook.live.com on Nightly139.0a1, Firefox128esr Windows11. And I can reproduce this even on Firefox91.

zip, mp4 are also affected.
So, seems irrelevant to the file type.

Comment 7

[Alice0775 White]

This problem seems to be fixed by the following UA spoofing.

user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36");

(Unfortunately, Chrome Mask does not help.)

Comment 9

[:Gijs (he/him)]

(In reply to Alice0775 White from comment #6)

(In reply to Tom Schuster (MoCo) from comment #5)

Does this reproduce with files that are not PDFs?

I can reproduce the issue with https://outlook.live.com on Nightly139.0a1, Firefox128esr Windows11. And I can reproduce this even on Firefox91.

zip, mp4 are also affected.
So, seems irrelevant to the file type.

Could you provide the full response headers in a broken case (minus any privacy-sensitive auth bits)?

Comment 10

[Alice0775 White]

(In reply to :Gijs (he/him) from comment #9)

Could you provide the full response headers in a broken case (minus any privacy-sensitive auth bits)?

HTTP/2 200 
cache-control: private
content-type: application/pdf
expires: Wed, 23 Apr 2025 11:44:45 +0000
server: Microsoft-HTTPAPI/2.0
x-nanoproxy: 1,1
request-id: **-**-**-**-**
x-backend-end: 2025-04-24T11:44:45.956
x-calculatedfetarget: TYWPR01CU003.internal.outlook.com
content-disposition: attachment; filename*=UTF-8''Backup.pdf
x-feserver: OS7PR01CA0042
access-control-allow-origin: https://outlook.live.com
access-control-allow-credentials: true
ms-cv: **.1.1
x-content-type-options: nosniff
access-control-expose-headers: Content-Disposition
x-backend-begin: 2025-04-24T11:44:45.800
x-backendhttpstatus: 200,200
x-besku: WCS7
x-calculatedbetarget: TY7PR01MB14474.jpnprd01.prod.outlook.com
x-feefzinfo: HND
x-frame-options: SAMEORIGIN
x-owa-httphandler: true
x-owa-minimumsupportedowsversion: V2_6
x-owa-owsversion: V2018_01_18
x-owa-version: 15.20.8655.31
x-proxy-backendserverstatus: 200
x-proxy-routingcorrectness: 1
x-responseorigin: OwaAppPool
x-rum-notupdatequeriedpath: 1
x-rum-notupdatequerieddbcopy: 1
x-rum-validated: 1
x-ua-compatible: IE=EmulateIE7
x-firsthopcafeefz: ITM
alt-svc: h3=":443";ma=2592000,h3-29=":443";ma=2592000
strict-transport-security: max-age=31536000; includeSubDomains
nel: {"report_to":"NelOfficeUpload1","max_age":7200,"include_subdomains":true,"failure_fraction":1.0,"success_fraction":0.01}
report-to: {"group":"NelOfficeUpload1","max_age":7200,"endpoints":[{"url":"https://exo.nel.measure.office.net/api/report?TenantId=&FrontEnd=Cafe&DestinationEndpoint=ITM&RemoteIP=**:**:**::&Environment=MT"}],"include_subdomains":true}
set-cookie: ClientId=****; expires=Fri, 24-Apr-2026 11:44:45 GMT; path=/;SameSite=None; secure
set-cookie: ClientId=****; expires=Fri, 24-Apr-2026 11:44:45 GMT; path=/;SameSite=None; secure
set-cookie: UC=77ebd41347b6411aabb784527e6dfe28; path=/;SameSite=None; secure; HttpOnly
set-cookie: RoutingKeyCookie=***; expires=Sat, 24-May-2025 11:44:45 GMT; path=/;SameSite=None; secure; HttpOnly
date: Thu, 24 Apr 2025 11:44:44 GMT
X-Firefox-Spdy: h2

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Can you give the response headers with the user agent override where it works?

Comment 12

[Andrew McCreight [:mccr8]]

I've added Outlook to the summary, to hopefully reduce the number of dupes people file.

Comment 13

[Alice0775 White]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)

Can you give the response headers with the user agent override where it works?

HTTP/2 200 
cache-control: private
content-type: application/pdf
content-encoding: gzip
expires: Wed, 23 Apr 2025 13:46:01 +0000
vary: Accept-Encoding
server: Microsoft-HTTPAPI/2.0
x-nanoproxy: 1
request-id: **-**-**-**-**
x-backend-begin: 2025-04-24T13:46:01.641
x-calculatedbetarget: OSCPR01MB14471.jpnprd01.prod.outlook.com
content-disposition: attachment; filename="Backup.pdf"
x-feserver: OS7P286CA0016
access-control-allow-origin: https://outlook.live.com
access-control-allow-credentials: true
x-content-type-options: nosniff
access-control-expose-headers: Content-Disposition
x-backend-end: 2025-04-24T13:46:01.734
x-backendhttpstatus: 200
x-besku: WCS7
x-frame-options: SAMEORIGIN
x-owa-httphandler: true
x-owa-minimumsupportedowsversion: V2_6
x-owa-owsversion: V2018_01_18
x-owa-version: 15.20.8678.24
x-proxy-backendserverstatus: 200
x-proxy-routingcorrectness: 1
x-responseorigin: OwaAppPool
x-rum-notupdatequeriedpath: 1
x-rum-notupdatequerieddbcopy: 1
x-rum-validated: 1
x-ua-compatible: IE=EmulateIE7
x-firsthopcafeefz: ITM
alt-svc: h3=":443";ma=2592000,h3-29=":443";ma=2592000
strict-transport-security: max-age=31536000; includeSubDomains
ms-cv: **g.1
nel: {"report_to":"NelOfficeUpload1","max_age":7200,"include_subdomains":true,"failure_fraction":1.0,"success_fraction":0.01}
report-to: {"group":"NelOfficeUpload1","max_age":7200,"endpoints":[{"url":"https://exo.nel.measure.office.net/api/report?TenantId=&FrontEnd=Cafe&DestinationEndpoint=ITM&RemoteIP=2001:ce8:114::&Environment=MT"}],"include_subdomains":true}
set-cookie: ClientId=**; expires=Fri, 24-Apr-2026 13:46:01 GMT; path=/;SameSite=None; secure
set-cookie: ClientId=**; expires=Fri, 24-Apr-2026 13:46:01 GMT; path=/;SameSite=None; secure
set-cookie: ***; path=/;SameSite=None; secure; HttpOnly
set-cookie: ***@hotmail.com; expires=Sat, 24-May-2025 13:46:01 GMT; path=/;SameSite=None; secure; HttpOnly
date: Thu, 24 Apr 2025 13:46:01 GMT
X-Firefox-Spdy: h2

Comment 14

[Jeff Muizelaar [:jrmuizel]]

So it sends content-disposition: attachment; filename="Backup.pdf" instead of content-disposition: attachment; filename*=UTF-8''Backup.pdf

Comment 15

[:Gijs (he/him)]

FWIW from some debugging, it would appear that something in Outlook takes that information and sticks it on an <a href="blob:..." download="UTF-8filename"> link itself. Firefox then downloads the file and obediently uses the name that Outlook gave it.

I suspect some of the JS logic in the outlook web app does not expect the UTF-8 content-disposition information itself. But all the JS is minified. The JS stack I have for the click on this link is:

0 f(e = ""blob:https://outlook.live.com/bffdeec2-80d2-407e-9d13-452136d2d075"", t = ""UTF-8filename.pdf"", r = "[object HTMLDivElement]", n = "false") ["https://res.public.onecdn.static.microsoft/owamail/hashed-v1/scripts/owa.66689.m.9483ecee.js":1:4073]
1 p() ["https://res.public.onecdn.static.microsoft/owamail/hashed-v1/scripts/owa.66689.m.9483ecee.js":1:3574]

which is not amazingly helpful.

Comment 16

[Jeff Muizelaar [:jrmuizel]]

The filename that the download attribute is getting set to is coming from the Outlook misparsing the content-disposition header:

            o = e.headers.get('Content-Disposition') ||
            '',
            a = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/.exec(o);
            return a &&
            a[1] &&
            (n = a[1].replace(/['"]/g, '')) &&
            (n = decodeURIComponent(n)),

Comment 17

[jscher2000]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16)

The filename that the download attribute is getting set to is coming from the Outlook misparsing the content-disposition header:

            o = e.headers.get('Content-Disposition') ||
            '',
            a = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/.exec(o);
            return a &&
            a[1] &&
            (n = a[1].replace(/['"]/g, '')) &&
            (n = decodeURIComponent(n)),

Thanks, I deconstructed that for the web console so I could understand where it is going wrong:

o = "attachment; filename*=UTF-8''test.docx";
// parse the header to extract the filename
a = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/.exec(o);
console.log(a[0]);
console.log(a[1]);
// remove the ' characters
n = a[1].replace(/['"]/g, '');
console.log(n);
// convert URI encoding back to text
console.log(decodeURIComponent(n));

While removing the ' characters seems like routine cleaning, they are failing to first detect the combination UTF-8'' as a special case that all needs to be removed completely.

Apologies for blaming Firefox and thank you for reaching out to Microsoft.

Comment 18

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1961710 - add a webcompat intervention for Outlook to fix downloaded attachments' filenames; r?denschub

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b936c8dd5056
add a webcompat intervention for Outlook to fix downloaded attachments' filenames; r=denschub,webcompat-reviewers

Comment 20

[Thomas Wisniewski [:twisniewski]]

Comment on attachment 9481159 [details]
Bug 1961710 - add a webcompat intervention for Outlook to fix downloaded attachments' filenames; r?denschub

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Users will continue to get incorrect filenames when downloading attachments from Outlook email services.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Log in to any Outlook email service (like Hotmail), and try to download any binary email attachment (you can send yourself a text file with a file extension like .bin to mimic this). Said attachment should download without an extra "UTF-8" prepended to its name.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This only affects network requests to Outlook email attachment domains, only changes one HTTP header's value as needed, and only involves code changes to our self-contained webcompat built in addon.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 21

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/b936c8dd5056

Comment 23

[jwsj]

So this is being blamed on Outlook despite it never happening until the last upgrade of Firefox? Pitiful. Undo the last "upgrade". Never mind. I'm done with Firefox.

Comment 24

[Dennis Schubert [:denschub]]

We're shipping an intervention now, adding the right flag.

Comment 25

[Dianna Smith [:diannaS]]

Attachment: Bug 1961710 - add a webcompat intervention for Outlook to fix downloaded attachments' filenames; r?denschub

Original Revision: https://phabricator.services.mozilla.com/D246746

Comment 26

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/faa00cfdb8e8

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/releases/mozilla-release/rev/bb92bc033bdd
disable webcompat's browser_custom_functions.js for permanent test failure

Comment 28

[Ina Popescu, Desktop QA]

I was able to reproduce the issue by following the STR from Comment 20 on macOS 13 using Firefox 137.0.2 I also verified that the issue is fixed in the latest Nightly 140.0a1, Firefox 139.0b2 and 138.0.1 on macOS 13, Windows 10 and Ubuntu 22.04 where filenames are downloaded correctly without the "UTF-8" prefix.

Comment 29

[PotIn]

Thx ! What about ESR version ?

Comment 30

[Jeff Muizelaar [:jrmuizel]]

(In reply to PotIn from comment #29)

Thx ! What about ESR version ?

Microsoft is in the process of deploying a fix so we don't plan on shipping the intervention on ESR.