Proxy Problem / Bug?

[cbaumann]

Hello,
I found the following problem in Wingates http-proxy:

On a server the following programs are installed:
* Wingate 6.0.3 (1005)
* Three http-servers on ports 80, 81, 88
* Wingate http-Proxy (for request from internal Lan) is enabled

The server name is e.g. test.xxx.at.

A html page (served from test.xxx.at:81) contains links to a css (test.xxx.at:80/somecss.css) and to an image (test.xxx.at:88/someimage.jpeg).

When the page is reloaded in a webbrowser it happens, that 1 or 2 of the 3 requests return a 404-not found. A TCP-trace and the server-logfiles show, that the Wingate proxy seems to "not use the different serverports correctly" and e.g. requests the somecss.css and someimage.jpeg from the server at port 81 (instead of 80 and 88).

It _looks like_ the problem has something to do with the following http-Headers:
* Proxy-Connection: Keep-Alive
* If-Modified-Since: ...

Regards
Chris

[genie]

Hi, Chris

A couple of questions:

What client are you using?
Is it plain proxy connect from the client, transparent redirection or simple NAT?

[cbaumann]

Hi, Chris

A couple of questions:

What client are you using?

Is it plain proxy connect from the client, transparent redirection or simple NAT?

Hi,
I have tested it with the following Clients:
* MS-IE 6.0.2800.x
* Firefox 0.9 and 1.0
* Opera 7.23

It ist a "normal" proxy connect, NO redirection or NAT.

Please note, that the http-servers are on the same machine as Wingate.

I _think_ the problem occurs, when the client uses http/1.1 to connect to the proxy e.g.: when the client uses ONE socket to the proxy (and requests the three ressources from the three http-servers), the problem occurs, when a client (e.g. Mozilla 1.7) openens (in my case) three sockets to the proxy it seems to work.
Hope this helps ...


Chris

[genie]

Hi, Chris

Can you run traffic capture on wingate machine on ports 80-83 and send us the dump? Looks like we might have a problem with keep-alive-marked connections.

[cbaumann]

Hi, Chris

Can you run traffic capture on wingate machine on ports 80-83 and send us the dump? Looks like we might have a problem with keep-alive-marked connections.

... find a log here: http://test.baumann.at/temp/Wingate_ProxyProblems.log

it it enough to analyze the problem?

Chris

[genie]

Wel,, not really - I still can't see what requests our proxy server is sending.... Can you allow all the logging for the proxy server and check the logfile after the request is done?

[cbaumann]

Can you allow all the logging for the proxy server and check the logfile after the request is done?

Hi,
... do you mean the content of "WWW Proxy Server.log", like (all the logging for ProxyServer was turned on)

11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Created:
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Requested: http://test.baumann.at:81/td/
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session sending server request in thread ed4
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: Server response contains 2346 bytes of resource data
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session processing HTTP response in thread ed4 - response code 200
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Traffic 2643 434 372 2637 0s
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Requested: http://test.baumann.at/cb2.css
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session sending server request in thread ed4
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: Server response contains 205 bytes of resource data
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session processing HTTP response in thread ed4 - response code 404
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: Unintercepted Server Response code 404
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Traffic 412 500 441 406 0s
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Requested: http://test.baumann.at:88/TD_DAT.gif
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session sending server request in thread ed4
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: Server response contains 208 bytes of resource data
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: WWW Session processing HTTP response in thread ed4 - response code 404
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Debug: Unintercepted Server Response code 404
11/30/04 07:29:29 192.168.1.3 Guest 0000003087 Traffic 415 499 437 409 0s
11/30/04 07:29:45 192.168.1.3 Guest 0000003087 Debug: Server closed connection in thread ed4
11/30/04 07:29:45 192.168.1.3 Guest 0000003087 Traffic 0 0 0 0 16s
11/30/04 07:29:45 192.168.1.3 Guest 0000003087 Terminated exit code 0

In this example the proxy server sent all the requests to http-server on port 81 - here is the log:

80.108.216.230 - - [30/Nov/2004:07:29:29 +0100] "GET /td/ HTTP/1.1" 200 2346
80.108.216.230 - - [30/Nov/2004:07:29:29 +0100] "GET /cb2.css HTTP/1.1" 404 205
80.108.216.230 - - [30/Nov/2004:07:29:29 +0100] "GET /TD_DAT.gif?doctitle=baumann.at%20-%20Test-%20und%20Demoseiten&docurl=http://test.baumann.at:81/td/&referrer= HTTP/1.1" 404 208


-> is this what you mean?
Tell me what I can do (more) to provide the information you need ...

Regards,
Chris

[genie]

Looks ok to me... Can you try requesting the resource directly from the client, like that: http://test.baumann.at:88/TD_DAT.gif
?

[cbaumann]

Looks ok to me... Can you try requesting the resource directly from the client, like that: http://test.baumann.at:88/TD_DAT.gif
?

... sure

11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Created:
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Requested: http://test.baumann.at:88/TD_DAT.gif
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Debug: WWW Session sending server request in thread e38
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Debug: Server response contains 807 bytes of resource data
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Debug: WWW Session processing HTTP response in thread e38 - response code 200
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Debug: Pragma: no-cache in server response - disabling caching
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Traffic 1084 493 431 1078 0s
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Debug: Server closed connection in thread e38
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Traffic 0 0 0 0 0s
11/30/04 11:25:20 192.168.1.3 Guest 0000003397 Terminated exit code 0




11/30/04 11:26:39 192.168.1.3 Guest 0000003401 Created:
11/30/04 11:26:39 192.168.1.3 Guest 0000003401 Requested: http://test.baumann.at/cb2.css
11/30/04 11:26:39 192.168.1.3 Guest 0000003401 Debug: WWW Session sending server request in thread ebc
11/30/04 11:26:39 192.168.1.3 Guest 0000003401 Debug: WWW Session processing HTTP response in thread ebc - response code 304
11/30/04 11:26:39 192.168.1.3 Guest 0000003401 Traffic 123 593 534 163 0s

##### Reload

11/30/04 11:26:42 192.168.1.3 Guest 0000003401 Requested: http://test.baumann.at/cb2.css
11/30/04 11:26:42 192.168.1.3 Guest 0000003401 Debug: WWW Session sending server request in thread ebc
11/30/04 11:26:42 192.168.1.3 Guest 0000003401 Debug: Server response contains 639 bytes of resource data
11/30/04 11:26:42 192.168.1.3 Guest 0000003401 Debug: WWW Session processing HTTP response in thread ebc - response code 200
11/30/04 11:26:42 192.168.1.3 Guest 0000003401 Traffic 910 527 468 904 3s
11/30/04 11:26:57 192.168.1.3 Guest 0000003401 Debug: Server closed connection in thread ebc
11/30/04 11:26:57 192.168.1.3 Guest 0000003401 Traffic 0 0 0 0 15s
11/30/04 11:26:57 192.168.1.3 Guest 0000003401 Terminated exit code 0

... obviously works ;-)

Chris

[genie]

Just one more question while we are testing it - if you take Wingate out of the equation and connect to the server directly - will it display this GIF file correctly?

[genie]

Looks like we have found a bit of code responsible for this behavior - as soon as the tests are complete, we'll let you know.

[cbaumann]

... will it display this GIF file correctly?

well ... as the GIF is just for tracking (1x1 pixels, transparent), there is not much to see ...

[genie]

Ok, the bug is found and fixed - will be added in the new release.

[cbaumann]

Ok, the bug is found and fixed - will be added in the new release.

Great. Thanks for the "quick reaction".
Chris