packet format in connection between proxy and IE？这是我在新闻组上发的帖子，没有得到回答，请各位大侠指点迷津！

下面是我在新闻组上的帖子，没有得到解答，现在帖出来，希望各位大侠指点迷津！


=============================================================
对方第二次回复：


I can use one answer for the whole thing,.....\"I have no idea\".
I am not a developer.
I can not verify that you are even approaching it right to begin with
so I could not possibly comment on the results of the attempt.


--

Phillip Windell [CCNA, MVP, MCP]
pwindell@wandtv.com
WAND-TV (ABC Affiliate)
www.wandtv.com

---------------------------------------------------

我的第二次发问：

\"guitar\" wrote in message
news:uG41DlhYDHA.2632@TK2MSFTNGP09.phx.gbl...

 hi, Phillip Windell

 You are so kind!  Thank you!

 Do you know MS network monitor and MS DDK develop
 example: passthru? I add my redirection function in passthru and view my
 DbgPrint in software dbgview and refer network monitor.I implement http
redirection(installed in GateWay) as following:

 1.Get the http request from local, and then register the connection
info (the web server ip requested for and the connection sequence) in a
structure chained in memory which named as querytable_entry. So, each local PC
will have its unique entry structure in which chains its all http
connections info.
 2.Change the destination ip to proxy and destination port to 8080
and fix ip and tcp checksum then forward the packet to the internet.
 3.Get the response from the proxy:8080. Search the querytable for
the right entry and right connection registry   [  if ((response.source_ip ==
 connection.webserver_ip) && (response.sequence ==
 nnection.sequence+1))   ]
 4.Write back necessary info ( replace response.source_ip as
 connection.webserver_ip   and replace 8080 as 80), then fix the
checksum.

 The result :
 1.In MS network monitor, I found that the tcp three shackhands is
connected and the IE status bar print\" web site found, please wait...\"
 2.Then local send a GET Request packet(of course redirected to
proxy:8080)
 3.Then local send some other packet to some.microsoft.com site
 4.maybe timeout at proxy, proxy send .A...F. flag packet back,
accordingly local send ...R.. flag packet to proxy. The process
 [local.get_request--proxy; local<--proxy(.A...F.);
local--proxy(...R..) ] appear at least three times.

 From the result, I guess:
 1.The manipulated request is sent to proxy:8080 becourse of the tcp
 connection been built.
 2.The connection works not properly after local send the Get Request
packet.
 3.I found the packet content(proxy is set in IE) have some
difference from the normal packet content(proxy not set):
     proxy set:     GET http://www.google.com /HTTP /1.0
     proxy not set: GET / HTTP / 1.1

     proxy set:     proxy-connection:Keep-Alive
     porxy not set: Connection:Keep-Alive

     and so on....

     They are important in connection? Maybe these difference make my
Get Request packet not recognized by proxy, so I should add or change
thoese message next step.
 What should I do?


 thanx!

=============================================================
我的第一次提问
The difference of packet format between IE in proxy mode and not
in!
Yes I want to program a software to achieve transparent redirection
the same as WinGate does. So, I should get the detail about the packet format.

 ------------------------------------------------------------
对方的第一次回复

There may not even be a difference, but if there is, it should
only
  be:
 
  IE using a Proxy:
The packet will have the destination IP# of the site you want
to  go to but will have the MAC address of the Proxy\'s internal NIC
and  the socket Number of 80. The packet will go to the Default WebSite
of  IIS on the Proxy box. The Proxy ISAPI Filter running in IIS will
take  over from there.
 
  IE not using Proxy:
The packet will have the the destination IP# of the site you
want to go to but will have the MAC address of the Default Gateway
listed in the workstation\'s network settings instead of the Proxy\'s MAC
address. The Packet will have the socket Number of 80.
 
  So the only difference is the packet\'s Destination MAC Address.
  You will have to use a packet sniffer to verify this. I have never
  tested this myself but is simply based on my knowledge of how any
  TCP/IP networks function.

 
 



[编辑 -  8/15/03 by  lxyxd_2003]