Здравствуйте! У меня проблема следующего плана: ставлю перехват функции select и recv на IE (инжектирование, сплайсинг - всё, как учил Ms-Rem ). Задача - редактировать входящий траффик. Всё прекрасно работает, кроме одного: необходимо встроить поддержку сжатия gzip. Здесь начинаются проблемы... Для редактирования страницы нужно закачать её полностью, распаковать, отредактировать и запаковать. Это всё тоже происходит без сбоев. Но вот потом невозможно отдать всё это Internet Explorer'у. Как только прекращается загрузка страницы в мой буфер, IE прекращает вызовы функций select и recv на нужный сокет. В итоге данные отдать невозможно. Возникает вопрос: как IE узнаёт о полной загрузке страницы? Что ещё нужно перехватывать? Также любопытно, как IE узнаёт о том, что данные пришли и их можно читать? Понятно, что перед вызовом recv вызывается select с запросом на чтение. Но! При вызове функции select с запросом на чтение данных Internet Explorer всегда угадывает, что данные пришли! Значит, как-то он это узнаёт заранее! Перебрал кучу функций, но так и не понял всего механизма Помогите, пожалуйста, разобраться!
извраты с перехватами ни к чему в ИЕ. советую пользоваться BHO (Browser Helper Objects), в MSDN все подробно описано.
Cr4sh Wininet - это, конечно, хорошо, но мне желательна единая реализация на все браузеры. Опера wininet не использует. И под неё перехват WSARecv и WSAAsyncSelect работают на ура, благодаря тому, что там используются сообщения Windows. Простота тоже понятие относительное Сейчас мне проще перехватывать именно recv и select, т.к. весь код уже сделан и отработан. Осталась последняя проблема с gzip-сжатием на IE и ему подобных браузерах. Если понять, откуда он узнаёт о приходящих на сокет данных, то дело должно быть в шляпе d4rkeagle Это любопытный подход! Но в силу вышеуказанных причин пока от него воздержусь. Кстати, забыл сказать про некоторую особенность IE. При загрузке данных он всегда использует два сокета: один, собственно, для их получения, а второй - для чего-то ещё. На второй сокет всё время вызывается select для чтения и recv. В recv под данные выделяется буфер всего в 32 байта, и этот вызов всегда заканчивается возвращением в буфере одного символа - "!". Для чего это делается - непонятно. В описании функций winsock про это вообще ни слова, но в интернете нашёл в одной статье мельком упоминание об этом: якобы таким образом IE проверяет содержимое стека. Пробовал на подобные вызовы точно также возвращать символ "!", но ничего этим не добился.
Grear Осталась последняя проблема с gzip-сжатием на IE и ему подобных браузерах. А с https у тебя случаено проблем нет? ) Может просто убрать Accept-Encoding: gzip, deflate из заголовка?
хех)) как вы с помощью перехвата сокетов будете редактировать HTTPS трафик? Он же шифрованный идет.... ниче у вас не выйдет) а насчет gzip достаточно убирать заголовки...
С https у меня проблем нет и не будет, т.к. его редактирование в задачу не входит. Вырезать gzip из заголовков - это самый простой вариант. Но в том и проблема, что хочется обойтись без этого. На той же Опере обошёлся без вырезаний! И даже при загрузке нескольких страниц сразу на dial-up'е ничего не тормозит (если сравнивать с перехватом и без него). Если понять как IE узнаёт о пришедших данных на сокет до вызова select, то появится возможность имитации подобных событий (в Опере достаточно послать дополнительные message главному окну с указанием дескриптора сокета). И тогда всё будет работать без вырезания gzip, с экономией траффика. Нет ли предположений, как IE может узнавать о приходящих данных до вызова select?
Grear может стоит заглянуть в сорцы IE, вернее его либ которые он юзает и поискать ответы на вопросы там ...
