#android #http #download
#Android #http #Скачать
Вопрос:
Я обнаружил очень странное явление в Android. Я обнаружил, что при загрузке изображения через 3g вычисленный впоследствии sha1 отличается от того, что должно было происходить с файлом, который находится на сервере. После дальнейшего расследования я обнаружил, что изображение было фактически уменьшено и перекодировано. Похоже, что мой оператор мобильной связи (verizon) пытается оптимизировать файлы, которые я загружаю.
Мой вопрос в том, может ли кто-нибудь еще подтвердить, что мобильные сети могут оптимизировать ваш файл, прежде чем он попадет на ваше устройство? И если да, есть ли где-нибудь какая-нибудь настройка, чтобы я мог это отключить.
В моем приложении очень важно знать, что файл sha1 того, что я загрузил, равен тому, что сервер говорит, что это должно быть.
Вот найденная статья о том, как verizon оптимизирует передачу 3g.
Комментарии:
1. Добро пожаловать в мобильный мир … вы, вероятно, также обнаружите, что плата за использование данных для оптимизированного изображения взималась на основе исходного полноразмерного файла, а не оптимизированного. Они говорят, что только трафик порта 80 получает эту обработку, поэтому просто настройте новый порт прослушивания для своего сервера и вместо этого запустите этот порт. 8080, 81 и т.д…
2. Я боюсь их сети, их правил… Не могли бы вы создать все свои изображения с разрешением 72dpi? Таким образом, они могут не получить выборку?
3. @Eamorr Я мог бы попробовать это. Одно из решений, которое до сих пор работало для меня, — это сделать запрос «https» вместо запроса «http».
4. Способ сделать это по протоколу https — это то, о чем я не подумал. Очень хорошее быстрое решение, если вам удобно.
5. Я тоже был свидетелем такого поведения на t-mobile.
Ответ №1:
Вы не сказали, но давайте предположим, что это HTTP-соединение.
Короче говоря, они делают это для экономии полосы пропускания. 3G не является бесплатным!
Если вы напрямую запрашиваете ресурсы (GET), то вы находитесь во власти всех посредников, которые обрабатывают HTTP-ответ (т.Е. Прокси, шлюзы), и вы можете быть уверены, что они могут видеть тип MIME в заголовках и вести себя соответствующим образом.
Вы можете попробовать использовать HTTP Accept -заголовок в своем запросе и использовать q параметр, чтобы «намекнуть», что вам нужна максимальная точность.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Accept: image/png;q=1
q Диапазон значений от 0 до 1. Возможно, вам удастся избежать меньшего значения (чем 1). Пожалуйста, прочитайте связанный раздел для получения более подробной информации.
Вы также можете проверить входящий Content-Type заголовок; он может выявить, есть ли «объявленное» изменение качества или даже типа MIME. Возможно, он сообщает вам, что он сделал!
Было бы отлично, если бы «стандарт» выполнил свою работу за вас!
Если это не сработает, и вы уже контролируете серверную часть, используйте для него альтернативную текстовую кодировку, например Base64, которую посредники не могут «сжать» для вас. SOAP делает это с тех пор!
Если вам действительно действительно нужно обойти сжатие изображения, и Accept это не работает, вы должны сами прокси-такие запросы и перекодировать их с помощью MIME-типа, отличного от изображения, в ответе.
Если вы идете по маршруту самостоятельного прокси-сервера, вам, вероятно, может сойти с рук вызов ваших изображений application/octect-stream , который является типом MIME для «неинтерпретированных байтов». Это позволило бы более или менее передавать данные и, надеюсь, избавить посредников от «рук помощи» от ваших вещей!
Комментарии:
1. Параметр «q» в «Accept» предназначен для определения приоритета выбора формата, а не для управления сжатием в определенном формате.