I was debugging my Frupic Android app the other day, trying to rotate images according to the orientation stored in their exif headers.

The necessary Android class ExifInterface(String filename) to read exif information from local files was quickly set up, but I couldn’t get it to report the correct orientation, it always returned ORIENTATION_UNDEFINED (0).

After debugging my code for a while on my physical device, double and triple checking on my PC that the file to be downloaded actually contained correct exif information, I found out that the file on the phone was about 2kb smaller than the file on the PC and on the server.

I knew my phone was downloading the file over my German T-Mobile data connection, believing that T-Mobile does not touch the files when requesting the image directly. I also knew that T-Mobile does replace image URLs in HTML files to be able to cache requested images on a server close by and I also knew they might compress them. I assumed, T-Mobile would not binarily alter a file if it is directly requested.

Browsing to http://speed.telekom.de (only available from within their mobile data network), customers are able to alter the behaviour of T-Mobile’s transparent HTTP proxy:

• Compress Picture- and Video transfers (this reduces quality and filesize)
• Optimize transfer without loss in quality
• No optimazion

Default is to optimize the transfer without loss in quality, which apparently does remove all exif headers from downloaded images but is also told to remove comments from HTML code and doing other micro optimazion stuff.

While I can choose to enable exif headers for slightly more traffic, it’s clear that my Android App can not rely on the exif information being available, unless the images are downloaded over SSL. I guess I am just one of few who have actually hit this limitation and I do not mind it being there. Could have saved me a lot of debugging time though.