solprovider@xxxxxxxxxx wrote:
On 7/22/08, Rich Schumacher <rich.schu@xxxxxxxxx> wrote:Solprovider, While I agree with your sentiment that forward proxies can be very dangerous, I think you are jumping the gun with your statement doubting they have "any legitimate use today." Here is a a real-world example that I use at my current job. My employer operates a series of websites that are hosted in servers all around the country. A couple of these servers are located in Canada and run a site specifically geared towards Canadian customers. As such, they have Canadian IP addresses. A while back we wanted to inform our Canadian customers who visited our non-Canadian site that we have a site specifically for them. We easily accomplished this using the MaxMind geoIP database and could display whatever information we wanted when we detected a Canadian IP. The quickest way to QA this was for us to setup a proxy (Squid, in this case) and point our browsers at it. The server was already locked down tight with iptables, so all we had to do was open a (nonstandard) port to our specific gateway and we were all set. Doing this we can now masquerade as a Canadian customer and QA can make sure it works as planned. Forward proxies can also be used as another layer of cache that can greatly speed up web requests. Hope that clears the air a little bit as I feel there are several good examples where forward proxies can be useful. Cheers, RichThank you. I was wondering if anybody noticed the question at the end of my post. I am truly interested in the answer. How would you have handled this if forward proxies did not exist? Your answer was the forward proxy helped testing, not production. QA could test: - using real Canadian addresses. - using a network with specialized routing to fake Canadian and non-Canadian addresses. - faking the database response so specific addresses appear Canadian. Did the production system require using a forward proxy? I discourage using IP Addresses to determine geographical locations. Slashdot recently had an article about the inaccuracies of the databases. (IIRC, an area of Arizona is listed as Canadian, which might affect your system.) I checked the IP Addresses of Web spam to discover that recent submits were from: - Moscow, Russia (or London, UK in one database) - Taipei or Hsinchu, Taiwan - Apache Junction, AZ. Some databases place my IP Address in the next State south. "Choose your country" links are popular on the websites of global companies. (I dislike websites that force the country choice before showing anything useful. If the website is .com, assume the visitor reads English and provide links to other languages and country-specific information.) I believe cache does not depend on forward proxy. Any Web server with cache enabled should serve static pages from the cache without configuring a proxy. Specific scenarios with a front-end server specifically for cache seem more likely to use a reverse proxy. While this is how a recent project for a major website handled cache, I do not have good information about general practices. Am I missing something? Other ideas? solprovider
Hi. Me again butting in, because I am confused again.When users workstations within a company's local network have browsers configured to use an internal "http proxy" in order to access Internet HTTP servers, is this internal proxy system a "forward" or a "reverse" proxy ? I am not talking here about a generic IP Internet router doing NAT, I am talking specifically about a "web proxy". This HTTP proxy may also do NAT of course, but its main function I believe is to cache pages from external servers for the benefit of internal workstations, no ? If this is a forward proxy, then I do not understand the comment of Solprovider that seems to indicate that such things are obsolete and/or dangerous. At any rate, they are in use in most corporate networks I am aware of.
André --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|