solprovider@(protected):
> On 7/22/08, Rich Schumacher <rich.schu@(protected):
>> 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,
>> Rich
>
> Thank 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@(protected)
 "  from the digest: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)