tar.gz email attachments are mangled when downloading from office365.com




18 days ago
12 days ago


(Reporter: Ross Boylan, Unassigned, NeedInfo)


52 Branch

Firefox Tracking Flags

(Not tracked)




18 days ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20171005074949

Steps to reproduce:

Sent an email that had a .tar.gz file (produced by R) as an attachment to myself or another user @ucsf.edu.  It is hosted at office365.com.  Use firefox to log in to outlook for the web (OWA), find the message.  The file shows as the correct size, 211KB.  Click on the attachment and select download.  

Possibly related bugs: 610679 (refers specifically to double compression), 714805, 233407, 902503, 1269101, 

Actual results:

The resulting downloaded file is 325KB, and is corrupt as far as R i or tar is concerned.  Inspecting the file with unix file (in cygwin) says it is a gz file with lowest compression/highest speed.  gunzip produces a file named xxx.tar, but file shows this as a gz file with maximum compression.  I'm not sure if it's identical to the original attachment, but it is about the right length.  If renamed to end .tar.gz the resulting file is useable.

So the file that ends up on my disk is my original file with a second layer of gzip compression on top of it.

The second layer of "compression", apart from making the file uninterpretable, makes it ~ 50% larger.

Expected results:

The file in the attachment, my original file, should have ended up on my disk.

The correct behavior happens with either MS IE or Chrome.

I have tried this on multiple physical systems, multiple versions of Windows (7 and 2012 R2), and multiple versions of FF (32 bit ESR or 64 bit current)--probably also multiple versions of the other browsers too.  All systems are running 64 bit windows.  I think I've seen the same problem with FF on Debian GNU/Linux 64 bit, but am not 100% sure. And, since the original problem happened when I sent the file to someone else, it's been tested under a different user (who used FF on Win7).  A campus tech support person experienced the same problem with the same file--so at least 3 people experience the same problem.

I do not know what protocols are being used when I hit download for the file attachment.

Comment 1

18 days ago
On the protocols used, I did the download again with the console open.  It shows 
 and the response headers include 
Cache-Control private
Content-Dispositionattachment; filename*=UTF-8''LazarSim_0.9-1.tar.gz
Content-Encoding gzip
Content-Type  application/gzip; authoritative=true;
Strict-Transport-Security  max-age=31536000; includeSubDomains
Vary Accept-Encoding
X-BEServer BY2PZ05MB1957
X-BackEnd-Begin   2017-11-04T01:30:48.056
X-BackEnd-End   2017-11-04T01:30:48.259
X-BackEndHttpStatus   200
X-CalculatedBETarget BYZPR05MB1957.namprd05.prod.outlook.com
X-Content-Type-Options  nosniff
X-DiagInfo   BZ2PR05MB1957
X-FEServer BZ2PR02CA0123
X-Firefox-Spdy  h2
X-Frame-Options SAMEORIGIN
X-UA-Compatible IE=EmulateIE7

I've omitted other info that looked either irrelevant or possibly security-exposing.

P.S. I would be nice if I could copy and paste from the log without having to manually restore the formatting.


18 days ago
Component: Untriaged → Networking
Product: Firefox → Core
Hi Ross,

I don't have a office 365 hosted mail account (so I use outlook.live.com instead), sending an email from gmail.
The mail includes an attachment, a tarball created by command |tar -czvf foo.tar.gz bar.txt|.
Then I download the file and check the SHA256 digest. It shows the file and the original one are identical.

We'd very like to fix this issue, so some more information is very helpful.
Would you:

- provide the log by following instructions on [1]
- see if you can reproduce this on public systems, so we can look into this more easily.


[1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Flags: needinfo?(RossBoylan)
You need to log in before you can comment on or make changes to this bug.