Basically, users can visit the website from different countries. And based upon the location of the user, the site displays relevant information.

That should be "based on the assumed location of the user."

I would suggest that you consider giving a little more control to the user regarding what is relevant. By all means provide content based on the location of the IP address, but also provide a means to provide alternative content if this is not relevant.

You need to consider that the IP address that you are seeing may be nowhere near the user - they may be connected through a VPN (for instance, bypassing 'the Great Firewall of China',) running through an anonymising service like tor or through a gateway connecting a private corporate network with the Internet at large. Assume away but let the user have the choice to correct your assumption if they so wish ;-)

As regards the logic of proxies, this is something with which you should probably familiarise yourself anyway. The environment variable $ENV{'REMOTE_ADDR'} is very often showing you a proxy (especially with ISPs that use transparent proxies, corporate networks again, etc.) rather than the IP address of the user. Which may be in a quite different geographic location from the user, if not in a different country.

I would suggest that you Google for X-Forwarded-For, the non-RFC-standard header used by many (but by all means not all) proxy servers to identify the 'real' IP of the client. This should be available to you - if set - as $ENV{'X-FORWARDED-FOR'}; note that this might come out as an array, as I believe that the header can have up to three parameters (if I remember correctly). There is another, similar, header that is sometimes used to perform the same function, but I can't remember it off the top of my head. You may come across it reading up on X-Forwarded-For.

And welcome to Perl Monks :-)

I'd personally settle for a mock object for the external code finding the country from the IP. Or script the web side to set the IP address of the GET request.

But then you can't test it easily from the web side exclusively, of course.

Personally, I wouldn't want to make myself dependent from some proxies that are out of my control. The Internet is not a very reproducible test environment for this sort of tests. So the question is: At which level do you want to (or: can you) control your test environment, e.g. application-level or network-level?

I assume, that you already have at least control over the test generators and the application? Several approaches are conceivable, depending on the degree of influence that you have upon your test environment (HW+SW, SW only) - and budget:

• HW1: use a test-PC and configure it's network card with the IPs you want to test / arrange proper routing
• HW2: configure a NAT-capable (network address translation) device in your network (e.g. a load balancer), mapping your current test-PCs IP to the ones desired / if I remember correct, there are NAT devices available that can map a source IP+port to a destination IP+port, so your test client can control the IP address by selecting a destination port
• SW1: enhance your application to accept an additional (CGI?) attribute, e.g. (__TESTIP=12.34.56.78) that overrides the current IP address value / you might want to disable this feature in a production environment / risk to introduce new errors
• SW2: Don't know it this really works: Setup some virtual machines with their individual IPs using the same physical NIC (e.g. Solaris Zones)

For what its worth, many browsers allow to define a preferred language, e.g. my browsers sends an Accept-Language: de,en;q=0.9 with each request... maybe it gives you further clues to present your localised content? IF you want to decide what language to use for display, then I would even consider country detection based on the IP as a fallback when no language preference was given by the client.