Question

I have found a very strange occurrence in Android. I have found that when downloading an image over 3g the sha1 computed afterwards is different than what it should have been occording to the file that is on the server. Upon further investigation, I found that the image was actually down sized and re-encoded. It would appear that my mobile carrier (verizon) is trying to optimize files that I’m downloading.

My question is, can anyone else confirm that mobile networks might optimize your file before it lands on your device? And if so, is there a setting somewhere somehow so that I can disable this.

It’s very important in my app to know that the file’s sha1 of what I’ve downloaded equals what the server says it should be.

Here’s an article found about verizon optimizing 3g transfers.

Answer 1

You didn’t say, but let’s assume this is an HTTP connection.

In short, they are doing it to save bandwidth. 3G isn’t Free!

If you are directly requesting resources (GET), then you are at the mercy of all intermediaries that process the HTTP response (i.e. proxies, gateways), and you can be sure they can see the MIME type in the headers, and behave accordingly.

You can try using the HTTP Accept header in your request, and use the q parameter to “hint” that you want maximum fidelity.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Accept: image/png;q=1

The q ranges from 0 to 1. You may be able to get away with a lower value (than 1). Please read the linked section for more details.

You can also inspect the incoming Content-Type header; it may reveal if there’s a “declared” change in quality or even MIME type. It may be telling you what it did!

It would be excellent if the “standard” does its job for you!

If that doesn’t work, and you are in control of the server end already, use an alternate text-based encoding for it, like Base64, that intermediaries cannot “compress” for you. SOAP has been doing that since ever!

If you really really need to bypass image compression, and Accept doesn’t work, you must proxy those kinds of requests yourself, and re-encode them with a non-image MIME type in the response.

If you are going the self-proxy route, you could probably get away with calling your images application/octect-stream which is the MIME type for “uninterpreted bytes”. This would allow for more-or-less pass-through of the data, and hopefully keep intermediaries “helping hands” off your stuff!