How is Outlook Online downloading attachments?

I’m trying to understand how the “Download All” button works in Office365 Outlook Online when downloading multiple attachments from an email.

The button is a “button” type. It does not appear to be part of a form. It has some “click” event listeners (apparently using React), but I’m not able to understand if those are somehow resulting in the download firing.

<button type="button" class="ms-Button ms-Button--action ms-Button--command _36CbeMUul160_BaOc004Od _25PDIRwPTbbCvgI4wMWgWF root-133" data-is-focusable="true">
  <span class="ms-Button-flexContainer flexContainer-78" data-automationid="splitbuttonprimary">
    <span class="ms-Button-textContainer textContainer-79">
      <span class="ms-Button-label label-49" id="id__875">Download all</span>
    </span>
  </span>
</button>

When I click it, Chrome doesn’t show a network event at all in the Network tab. Firefox shows it as a GET request, and it doesn’t look like XmlHttpRequest (no Origin header etc):

Request:

URL:https://outlook.office365.com/owa//service.svc/s/GetAllAttachmentsAsZip?id=...&X-OWA-CANARY=...
Request Method:GET
Remote Address:40.97.221.114:443
Status Code:
200
Version:HTTP/1.1
Referrer Policy:no-referrer

Host: outlook.office365.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Cookie: ...
Upgrade-Insecure-Requests: 1

Response:

HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/zip; authoritative=true;
Content-Encoding: gzip
Expires: Mon, 20 Jan 2020 02:34:12 +0000
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
request-id: ...
X-CalculatedFETarget: MAXPR0101CU002.internal.outlook.com
X-BackEndHttpStatus: 200
X-FEProxyInfo: MAXPR0101CA0031.INDPRD01.PROD.OUTLOOK.COM
X-CalculatedBETarget: MAXPR01MB2735.INDPRD01.PROD.OUTLOOK.COM
X-BackEndHttpStatus: 200
X-RUM-Validated: 1
X-MailboxGuid: ...
X-Content-Type-Options: nosniff
X-BeSku: WCS5
x-ms-appId: ...
X-OWA-Version: 15.20.2644.27
X-OWA-OWSVersion: V2018_01_18
X-OWA-MinimumSupportedOWSVersion: V2_6
X-Frame-Options: SAMEORIGIN
X-OWA-HttpHandler: true
Content-Disposition: attachment; filename*=UTF-8''subject.zip
X-BackEnd-Begin: 2020-01-21T02:34:12.321
X-BackEnd-End: 2020-01-21T02:34:12.349
X-DiagInfo: MAXPR01MB2735
X-BEServer: MAXPR01MB2735
X-UA-Compatible: IE=EmulateIE7
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Proxy-RoutingCorrectness: 1
X-Proxy-BackendServerStatus: 200
X-FEServer: MAXPR0101CA0031
X-FEServer: BYAPR03CA0003
Date: Tue, 21 Jan 2020 02:34:11 GMT

I’m unable to tell what mechanism is used to fire this request: page navigation, XmlHttpRequest, Fetch?.. What makes the browser treat it as an attachment? I tried to intercept this response in Fiddler and change the response headers to

Content-Type: text/html
Content-Disposition: inline
Content-Length: 5

Hello

But the browser still downloads the response as a file, rather than rendering it inline. Why is that?

Answer

This is caused by a dynamically added anchor tag with a download attribute:

<a href="foo.zip" download>Download All</a>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#download

If Content-Disposition has a different filename than download, the header takes priority. (If Content-Disposition: inline, Firefox prefers the header while Chrome prefers download.)