Skip to content

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.

Download All button

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