On Tue, Jul 22, 2008 at 11:51 PM, <[EMAIL PROTECTED]> wrote: > 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? >
Well, if forward proxies did not exist we could have used Lynx (or any other text browser, or wget, etc) on our Canadian server to view the HTML returned by the server to determine if the appropriate content was included. When I mentioned QA, what I was really trying to say was they were able to sign off on the feature on both staging and production environments. In regards to faking the DB response: this is exactly what I did while I was developing and testing the feature. However, this is not feasbile on staging and production environments as the code should never be modified directly. Using the forward proxy was the easiest solution to our problem, without resorting to more advanced techniques you mentioned above. > > 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.) While researching, I understood that using IP addresses and the geoIP DB would not be 100% accurate. For our application, though, it was an acceptable solution. We are not serving completely different pages or content, but merely displaying some extra information to the user about our Canadian site. If we were running a multi-lingual, global site then yes, specific domains with appropriate language would be the best solution. So if a user is mistakenly tagged as coming from Canada, the most they will see is an extra banner link and some text. From what I understand, we haven't had any negative feedback since this was implemented. But, that reminds me that I should follow up on this and possibly implement a "Not from Canada? Click here..." feature. > > 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. Cache, per se, is not explicity tied to any kind of proxy. I feel I somewhat mispoke above and made a very ambiguous statement. In terms of backend, typical scaling migration goes from the web servers storing cache directly (either disk or memory) to having a pool of dedicated cache servers or using a hardware device (F5 BIG-IP, NetScalars, etc). What I meant to imply was that a forward proxy can catch local requests before they hit the internet at large and serve the response from within their local cache. They can also be used to filter web requests. This is typically implemented by ISP's and corporate networks in a dedicated hardware device. Along those lines...I use a forward proxy over SSH at work to circumvent our local web filter, but I guess that's not considered a "legitimate" use. :) > > > --------------------------------------------------------------------- > 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: [EMAIL PROTECTED] > " from the digest: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
