Geographic location / filtering and HTTP caching

Question

I am trying to add cache support (both HTTP and server) for an ASP.NET Web Api solution.

The solution is in geolocation, which means that I can get different results based on the IP address of the caller.

The issue can be trivially resolved for the server-side cache using an approach similar to VaryByCustom ( like this one ). However, this does not solve the problem with HTTP caches on the client side. Here are the alternatives

I am considering the following options:

• Coercion is necessary-revalidate in cache

  Save the server side of the validation using the same algorithm as VaryByCustom, but enable additional server side call cache re-processing using ETAGS or any mechanism that tracks the original country of origin of the cache.

• Creating country-specific routes for HTTP 302

  In this case, the application calling

  http://site/UK/content 

  Redirecting to the US version, if it comes from the US IP address, when the cache expired.

   http://site/US/content 

  It may contain outdated content that does not match the IP address of the local source. This is not a serious problem if the cache expires, this is a small value (<1 hour), because changes in the country are quite unusual.

What is the recommended solution?

Answer 1

After a detailed assessment, the first approach was chosen. Actual implementation:

• Create a cache key that depends on the IP address of the country of origin.
• Create an ETag for this cache key and store it in the server cache
• Additional requests, which include the ETag If-None-Match header, are evaluated on the server for a cache glow:
  • If the country of origin is the same, the cache key will be the same and the ETag will be valid, returning HTTP 304 not changed
  • If the country of origin is different, the cache key will be different, and such an ETag is invalid, returning an HTTP 200 and returning a new ETag.

Agree with Poul-Henning Kamp Geolocation should be transportable, but unfortunately not, so this is the only way we could come to provide cache freshness for a given country.

The disadvantage is that there can be no infrastructure cache, for example, all requests must check the server for cache freshness.

Answer 2

I'm not sure I understand the problem.

For client caching, if you enable private caching, a user in the UK will cache the UK version of http://site/content , and a US user will cache the version of http://site/content in the USA.

The only problem I see is the user’s trip from the US to the UK and access to content. Or, if you enable public caching, and some intermediary is used by users in the US and the UK.