Ситуация такая: В драйвере успешно перехватывается TDI_SEND, оттуда берется HTTP запрос, вытаскивается URL нужно сделать так, чтобы при определенном URL происходило перенаправление на другой сервер (по IP адресу) и отправлялся этот запрос туда. Соответственно если подсунуть обратно каким-то образом HTTP response с редиректом, тоже будет хорошо. умею делать перенаправление при создании соединения, но это не подходит, т.к. в этот момент не понятно какой URL будет. умею закрыть текущее соедение, браузер при этом говорит - сервер не найден. тоже не подходит. есть вариант перехватить receive и поменять ответ от сервера, но мне кажется это слегка через Ж и соединение с изначальным сервером будет создано. в общем не знаю с какой стороны подойти к этому вопросу, подскажите подалуйста.. наверняка кто-то уже сталкивался....
Для коррекции tcp/ip заголовков, в т.ч. IP-адреса исходящего соединения нужно лезть на NDIS-уровень или работать с \Device\RawIp. Для TDI уровня нужно перехватывать TDI_SEND и TDI_RECIEVE (в большинстве случаев запрос клиента и ответ сервера возвращаются в TDI_SEND).
IP адрес и порт можно изменить на TDI уровне перехватывая \Device\Tcp и евент TDI_CONNECT, и я не понимаю какие могут быть противоречия этому. ответ от сервера возвращеается в TDI_EVENT_RECEIVE. с этим проблем нет.. проблема в том, что хочется не оптправлять данные серверу, ждать ответа, а выдать ответ наверх сразу (с HTTP заголовком) и закрыть соедиение.
это сильно... по сабжу - сделайте прокси. Прокси может быть как прямо в вашем TDI фильтре ( это довольно таки трудоемко, но круто ), так и в отдельном юзермодном процессе. В последнем случае, в качестве прокси можно взять какое нибудь готовое изделие, а в TDI фильтре просто подправлять запросы TDI_CONNECT перенаправляя их на собственный лоакльный прокси-сервер.
Я хотел сказать, что перехватывать нужно TDI_SEND Уважаемый TarasCo! Вот ссылочка на ВАШ ЖЕ БЛОГ - http://tarasc0.blogspot.com/2006/10/blog-post_01.html. Там в самом низу Вы некоему Алексею на вопрос Там речь шла о создании фильтра над \Device\Tcp и перехвате соотвественно TDI_SEND и TDI_RECEIVE. Здесь по сути спрашивают то же самое - может умнее с Вашей стороны было бы не умничать по поводу?
Во первых TDI_RECEIVE вообще ничего не дает.. см. другие топики на этом же форуме.. С перехватом проблем нет. Проблема в том, как обмануть стек драйверов и запустить ответ из TDI юзерскому приложению... прокси на юзер моде не подойдет, т.к. нужно делать все незаметно. редиектить весь трафик на прокси в юзер моде конечно можно, но при этом потеряется IP назначения, т.к. он будет подменен. Для HTTP трафика проблем та нет, там хидер есть.. а вот если через порт 80 пойдет другой трафик - хана. А заранее узнать че это за протокол будет, неполучиться, т.к. нет данных. Правильный ответ, делать прокси на TDI. Но как и было отмечено, задача трудоемкая, конечно крутая.. но хочется малой кровью.. сейчас делаю с подменой ответа от сервера, т.е. перехватывая TDI_SEND я отмечаю это соединение как подлежашее редиректу и когда приходит ответ от HTTP сервера (перехватывается TDI_EVENT_RECEIVE и TDI_EVENT_CHAINED_RECEIVE) подменяю HTTP response чтобы получился редирект (Location: ....).
pinya Уверен? Проверь на практике. У меня в фильтре перехват TDI_RECEIVE дает перехват http примерно в 3 случаях из 10, все остальное проходит через перехват TDI_SEND. Так что игнорировать TDI_RECEIVE не стоит.
вот что там было написано: где-нибудь было упомянуто, что через обработку TDI_SEND можно получить ответ от сервера?? PS: кстати, кто Вам сказал, что это мой блог? Может мы тезки?
готов обсуждать про TDI_SEND и TDI_RECEIVE позже.. перехват и редирект у меня работает (способом описанным ранее). глюков пока не замечено. а значит и трогать не надо я может как-то несовсем внятно задал вопрос? но это потому, что яснее к сожалению не могу..., т.к. мне нужно направление в котором думать... мне мы в двух словах ктонить сказал.. возможно можно через NDIS, но хоть пару слов еще.. сам принцип.. как реализовать поди уже разберусь.. возможно прокси, это единственный способ. Вообще, очень похоже на то. Но может всетаки.... спасибо ICQ:18172224
