Why does my mobile operator recode the file when downloading?

Question

I found a very strange phenomenon in Android. I found that when uploading an image over 3g, the subsequently calculated sha1 is different from what was supposed to happen in the file located on the server. After further investigation, I found that the image was actually reduced in size and transcoded. It seems like my mobile operator (verizon) is trying to optimize the downloads.

My question is: can anyone else confirm that mobile networks can optimize your file before it gets to your device? And if so, is there some kind of setting somewhere so that I can turn it off.

In my application, it is very important to know that the sha1 file from what I downloaded corresponds to what, according to the server, should be.

An article was found here that verizon optimizes 3g translations.

Answer 1

You did not say, but suppose this is an HTTP connection.

In short, they do this to save bandwidth. 3G is not free!

If you directly request 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 that 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 as a "hint" so that you have maximum accuracy.

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

 Accept: image/png;q=1 

q is between 0 and 1. You can leave with a lower value (than 1). Please read the related section for more details.

You can also check the incoming Content-Type header; it can show if there is a “claimed” change in quality or even a MIME type. This can tell you what he did!

It would be great if the "standard" did its job for you!

If this does not work, and you already control the end of the server, use an alternative text encoding for it, such as Base64, which intermediaries cannot compress for you. SOAP has been doing this since!

If you really need to bypass image compression, and Accept does not work, you should proxy these types of requests yourself and re-encode them with the MIME type without an image in the response.

If you go on a self-proxy route, you can probably get away with your application/octect-stream images, which is the MIME type for “uninterpreted bytes”. This would allow more or less to transfer data and, hopefully, keep intermediaries "helping hands" from your things!