Back in August a co-worker who is doing a lot of work with Office 365 noticed something changed in Office 365.  One of those sneaky, unannounced changes that break things inadvertently and take a while to track down.

It turns out Office 365, SharePoint Online in particular, had stopped Zipping returned  payloads to JavaScript Object Model (JS OM or JSOM), even if you explicitly asked for them.  You can read about his initial discovery in a blog post.

TL;DR – Send a request for information from SharePoint, include the “Accept-Encoding: gzip, deflate, sdch” header, response comes back without compression applied.

Here is it in action.  To try this at home you will need:

• One SharePoint Online site
• A tool like Fiddler or PostMan (handy Chrome app) for easily handcrafting and initiating HTTP requests and seeing what comes back.  I’m using it below.
• A list set up in your SharePoint site with some data in it

Create a HTTP GET request to return the items from your list. Something like this:

http://MySharePointOnlineSite.SharePoint.com/sites/Developer/_api/Lists/MoviesList/Items?$select=Title

Add your Accept-Encoding header and Accept headers like so to ask for JSON back and gzip compression:

Send your request and you should see some JSON come back.  Something like this:

Notice a distinct lack of zippage? Also if you flip to the Headers tab on the response you don’t see a Content-Encoding: gzip like this:

Now this isn’t really a big problem in the grand scheme of things.  Unless you are calling this from a mobile app where bandwidth is important or you need low latency replies. Another example would be if you are building a SharePoint App and calling the REST services to get back list data to drive some UI … you want it to be snappy.

After a bit of hunting my co-worker pointed me at a post about an SSL + HTTP Compression hack called BREACH.  Basically this hack lets hackers break SSL by fiddling with the input on a request and watching changes in the compressed response. After a few (say 1000) requests they can crack your SSL.  Note this is only an issue if you are serving content than can change based on manipulation of request data AND the return payload can be compressed.

The fix?  Turn off HTTP compression on responses.

Yes, really. That seems to be the only practical option for mitigating against this attack right now. No, this isn’t a bug in IIS or SharePoint or any other product.

Hence, this seems to be why SharePoint online no longer compresses responses.  I was told that static files might be compressed since they wont fall victim to this hack, however my testing didn’t surface any resources that I could make come back compressed. (Let me know if you find one)

E plan tenants  are the most effected I think as the SharePoint Online sites are all behind SSL.

I found this really interesting so I thought I would share.

-CJ

PS: thanks to my Microsoft buddies who helped confirm this for me.