ok folks,
I did some in depth analysis using TCPView from sysinternals.com and packetmon from analogx.com.
Here are the hexdumps of the conversation between my browser and the proxy:
A good Request should look like this (Web Shield off):
Browser:
47 45 54 20 68 74 74 70 3A 2F 2F 77 77 77 2E 67 GET
http://www.g
6F 6F 67 6C 65 2E 64 65 2F 67 72 70 68 70 3F 68 oogle.de/grphp?h
6C 3D 64 65 26 74 61 62 3D 77 67 26 71 3D 20 48 l=de&tab=wg&q= H
54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 74 3A TTP/1.1..Accept:
20 69 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 image/gif, imag
65 2F 78 2D 78 62 69 74 6D 61 70 2C 20 69 6D 61 e/x-xbitmap, ima
.....
Proxy:
48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D HTTP/1.1 200 OK.
0A 44 61 74 65 3A 20 53 61 74 2C 20 31 39 20 46 .Date: Sat, 19 F
65 62 20 32 30 30 35 20 32 33 3A 31 32 3A 30 37 eb 2005 23:12:07
20 47 4D 54 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 GMT..Content-Le
6E 67 74 68 3A 20 31 37 36 30 0D 0A 43 6F 6E 74 ngth: 1760..Cont
......
The "Bad-Request" (Web Shield On and trapping proxy communicatio to port 8080):
Browser (notice the missing server in the first line):
7 45 54 20 2F 69 6E 74 6C 2F 64 65 5F 41 4C 4C GET /intl/de_ALL
2F 69 6D 61 67 65 73 2F 67 72 6F 75 70 73 5F 68 /images/groups_h
70 2E 67 69 66 20 48 54 54 50 2F 31 2E 31 0D 0A p.gif HTTP/1.1..
41 63 63 65 70 74 3A 20 2A 2F 2A 0D 0A 52 65 66 Accept: */*..Ref
65 72 65 72 3A 20 68 74 74 70 3A 2F 2F 77 77 77 erer:
http://www2E 67 6F 6F 67 6C 65 2E 64 65 2F 67 72 70 68 70 .google.de/grphp
.....
Proxy:
48 54 54 50 2F 31 2E 31 20 35 30 30 20 53 65 72 HTTP/1.1 500 Ser
76 65 72 20 45 72 72 6F 72 0D 0A 44 61 74 65 3A ver Error..Date:
20 53 61 74 2C 20 31 39 20 46 65 62 20 32 30 30 Sat, 19 Feb 200
35 20 32 33 3A 31 37 3A 32 35 20 47 4D 54 0D 0A 5 23:17:25 GMT..
43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20 Content-Length:
32 31 32 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 70 212..Content-Typ
65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D 0A 53 65 e: text/html..Se
72 76 65 72 3A 20 4E 65 74 43 61 63 68 65 20 28 rver: NetCache (
4E 65 74 41 70 70 2F 35 2E 31 52 32 44 31 34 29 NetApp/5.1R2D14)
0D 0A 0D 0A 3C 48 54 4D 4C 3E 0A 3C 48 45 41 44 ....<HTML>.<HEAD
3E 3C 54 49 54 4C 45 3E 35 30 30 20 53 65 72 76 ><TITLE>500 Serv
65 72 20 45 72 72 6F 72 3C 2F 54 49 54 4C 45 3E er Error</TITLE>
3C 2F 48 45 41 44 3E 0A 3C 42 4F 44 59 3E 0A 3C </HEAD>.<BODY>.<
48 31 3E 53 65 72 76 65 72 20 45 72 72 6F 72 3C H1>Server Error<
2F 48 31 3E 0A 3C 48 34 3E 0A 54 68 65 20 66 6F /H1>.<H4>.The fo
6C 6C 6F 77 69 6E 67 20 65 72 72 6F 72 20 6F 63 llowing error oc
63 75 72 72 65 64 3A 3C 50 3E 0A 43 6F 75 6C 64 curred:<P>.Could
20 6E 6F 74 20 63 6F 6E 6E 65 63 74 20 74 6F 20 not connect to
74 68 65 20 73 65 72 76 65 72 0A 3C 2F 48 34 3E the server.</H4>
0A 3C 48 52 3E 0A 50 6C 65 61 73 65 20 63 6F 6E .<HR>.Please con
74 61 63 74 20 74 68 65 20 61 64 6D 69 6E 69 73 tact the adminis
74 72 61 74 6F 72 2E 0A 3C 2F 42 4F 44 59 3E 0A trator..</BODY>.
3C 2F 48 54 4D 4C 3E 0A </HTML>.
It seems that the request of the browser gets malformed or modified by Web Shield. The web-server is missing in the get request, so we get an error answer of the proxy.... But sometimes I also saw that the proxy didn't answer at all to this kinds of requests!
Alwil: Please also check, what happens to ssl and ftp requests, if they are also handled by the web shield and then forwarded to the provider-proxy... Most users (like myself) are lazy and simply check the mark "use the same proxy for all protocols" in their web browser...
But also maybe there isn't another solution for proxy users and we have to use the workaround of localhost:12080 and the avast.ini change. The workaround itself is quite logical and runs very fine indeed!
hmm... let's think about it....
In fact, if the proxy provider destination port is trapped to Web Shield (8080 in my case), then Web Shield has to handle and distinguish between the different protocols (http, ssl, ftp, gopher), because most of the provider-proxies use the same port for all protocols. Think of a person in a corporate lan, with only one proxy and only one port to talk to the internet... So, if Web Shield really expects only pure http-traffic to the "trapped" (or "redirected") port/ports, then there will be no other way, but the workaround....
Hope that Alwil can replay the problem.