URLOpenPullStream и загрузка содержимого gzip - нужны несжатые данные - PullRequest
Новая
       23

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

1 голос
/ 28 октября 2010

Я использую 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данные сам.В быстром тесте с использованием библиотеки gzip на C ++ я смог распаковать содержимое.Так что, это может быть вариант.Если это то, что мне нужно сделать, то лучший способ обнаружить это gzip.Я заметил, что получил событие OnProgress с BINDSTATUS_MIMETYPEAVAILABLE и текстом, установленным в «application / x-gzip-compress».Это как я должен это обнаружить?

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

1 Ответ

1 голос
/ 31 октября 2010

Я отвечу на свой вопрос после дополнительных исследований.Кажется, что веб-сайт, с которым у меня возникла проблема, возвращает что-то неправильное, когда 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 прозрачно обрабатывает распаковку.

Не знаю:)

...