Загрузка содержимого URLOpenPullStream и gzip — нужны несжатые данные

Я использую URLOpenPullStream вместе с обратными вызовами IBindStatusCallback и IHttpNegotiate для обработки сообщений о согласовании, статусе и данных. Проблема, с которой я сталкиваюсь, заключается в том, что содержимое является gzip (например, Content-Encoding: gzip). Данные, которые я получаю через OnDataAvailable, сжаты. Мне нужны несжатые данные. Я использую BINDF_PULLDATA | BINDF_GETNEWESTVERSION | Флаги привязки BINDF_NOWRITECACHE. Я прочитал несколько сообщений, в которых говорится, что он должен поддерживать формат gzip.

Сначала я попытался изменить заголовок запроса Accept-Encoding, чтобы указать, что мне не нужен gzip, но безуспешно. Я могу изменить или добавить заголовки в BeginningTransaction, но не могу изменить Accept-Content. Я смог изменить User-Agent и смог добавить новый заголовок, поэтому процесс работает, но по какой-то причине он не переопределяет Accept-Content.

Другой вариант — разархивировать данные самостоятельно. В ходе быстрого теста с использованием библиотеки gzip C++ мне удалось разархивировать содержимое. Так что, может быть, это вариант. Если это то, что мне нужно сделать, то лучший способ обнаружить это - gzip. Я заметил, что получил событие OnProgress с BINDSTATUS_MIMETYPEAVAILABLE и текстом, установленным на «application/x-gzip-compressed». Это как я должен обнаружить это?

Ищу любое решение, чтобы обойти эту проблему! Я хочу остаться с URLOpenPullStream. Это продукт, который был выпущен, и мы хотим, чтобы изменения были минимальными.


download c++ url gzip urlmon
person Ron    schedule 27.10.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я отвечу на свой вопрос после дополнительных исследований. Кажется, что веб-сайт, с которым у меня возникла проблема, возвращает что-то неправильное, когда IE, FF и URLOpenPullStream не распознают его как действительное содержимое gzip. Заголовки выглядят нормально, например.


  HTTP/1.1 200 OK
  Content-Type: text/html; charset=iso-8859-1
  Content-Encoding: none
  Server: Microsoft-IIS/6.0
  MSNSERVER: H: COL102-W41 V: 15.4.317.921 D: 2010-09-21T20:29:43
  Vary: Accept-Encoding
  Content-Encoding: gzip
  Content-Length: 4258
  Date: Wed, 27 Oct 2010 20:48:15 GMT
  Connection: keep-alive
  Set-Cookie: xidseq=4; domain=.live.com; path=/
  Set-Cookie: LD=; domain=.live.com; expires=Wed, 27-Oct-2010 19:08:15 GMT;   path=/
  Cache-Control: no-cache, no-store
  Pragma: no-cache
  Expires: -1
  Expires: -1

но URLOpenPullStream только что загрузил его в необработанном сжатом формате, IE сообщает об ошибке при попытке доступа к сайту, а FF показывает мусор.

После выполнения теста с сайтом, который действительно возвращает действительное содержимое gzip, например. www.webcompression.org, затем IE, FF и URLOpenPullStream работали нормально. Итак, похоже, что URLOpenPullStream поддерживает содержимое gzip. В данном случае он был прозрачным. В OnDataAvailable я получил несжатые данные, а в OnResponse заголовки не отображали Content-Encoding как gzip.

К сожалению, это все еще не решило мою проблему. Я решил, проверив заголовки ответов в событии OnResponse. Если Content-Encoding был gzip, то я устанавливал флаг и, когда загрузка была завершена, использовал подпрограммы zlib gzip для распаковки содержимого. Это, казалось, работало нормально. Это должно подойти для моего редкого случая, поскольку обычно я никогда не должен получать Content-Encoding : gzip в заголовках OnResponse, поскольку URLOpenPullStream прозрачно обрабатывает распаковку.

Не знаю :)

person Ron    schedule 31.10.2010
comment
Еще одно обновление по этому вопросу. Проблема была определена в том, что заголовки имели Content-Encoding как для none, так и для gzip. (можно увидеть выше). Браузер использовал первый none, но фактический контент был gzip. Веб-сервер не находится под моим контролем, поэтому, к сожалению, мне пришлось обнаружить это условие в заголовках и самостоятельно разархивировать содержимое. - person Ron; 04.01.2011