Kaare Rasmussen writes: > It has been necessary for me to move my mail server behind a NAT'ing firewall > (with a private IP-address). > Http-traffic is going to a central web server that rewrites requests to th > internal IP addresses. > > This is going very well except for sqwebmail! This is the only cgi-script > that insists upon failing!!
Any CGI script that makes the full use of CGI 1.1 environment variables will fail. A dumb CGI script that merely spits out some output, which is never used again, won't care, but full CGI application will depend on the CGI environment to accurately represent the client's view of the server. If some firewall in the middle screws around with the CGI environment, things will break. > I can see that it somehow manages to use the local (private) IP-address for sqwebmail does not use the local IP address. sqwebmail reads the CGI environment variables, from the HTTP request. The CGI environment variables are built from the HTTP headers, and they describe both the server and the client environment. If some firewall scrambles HTTP headers, the resulting CGI environment may not necessarily describe an accurate picture of reality. > something, so of course the client will never see a page. The browser just > times out. > > There must be something I can do about it?? Fix your firewall. A firewall has no business messing around with the HTTP request. A firewall should transparently pass along the client/server connection, without screwing around with its contents. That's what firewalls do. Sqwebmail has no way of knowing that something between the client and the server randomly scrambled the contents of the HTTP headers. If the firewall insists on messing around with the HTTP headers, the firewall then must also accept the responsibility for parsing the resulting HTTP output, and rewriting it also. But you cannot expect to rewrite only one side of the equation, and still have everything work. It doesn't work this way. -- Sam
