4

我正在尝试为 ASP.NET Web Api 解决方案添加缓存支持（HTTP 和服务器）。

该解决方案是地理定位的，这意味着我可以根据呼叫者 IP 地址获得不同的结果。

可以使用类似于 VaryByCustom的方法轻松解决服务器端缓存的问题（就像这个），可以轻松解决服务器端缓存的问题。但是，这并不能解决客户端 HTTP 缓存的问题。这里是替代品

我正在考虑以下选项：

  1. 强制执行必须重新验证在缓存中

    保持验证服务器端使用与 VaryByCustom 相同的算法，但使用 ETAGS 或任何跟踪原始缓存值来源国家/地区的机制在服务器端包含额外的缓存重新验证调用。

  2. 创建特定于国家/地区的路由HTTP 302

    在这种情况下，应用程序调用

    http://site/UK/content

    如果缓存过期时来自美国 IP 地址，则重定向到美国版本

    http://site/US/content

    它可能会显示与本地源 IP 不匹配的过时内容。如果缓存过期是一个小值（< 1 小时），这不是一个严重的问题，因为国家/地区更改相当少见。

推荐的解决方案是什么？

4

2 回答 2

0

我不确定我是否理解这个问题。

对于客户端缓存，如果您启用私有缓存，那么英国的用户将缓存英国版本的 .http://site/content美国用户将缓存美国版本的http://site/content.

我能看到的唯一问题是用户是否从美国前往英国并访问内容。或者，如果您允许公共缓存并且某些中介由美国和英国用户共享。

于 2013-06-04T17:12:19.873 回答
0

经过详细评估后，选择了第一种方法。实际实现是：

  1. 创建一个取决于来源国 IP 地址的缓存键
  2. 为该缓存键创建一个 ETag 并将其存储在服务器缓存中
  3. 包含 ETag If-None-Match 标头的其他请求在服务器中评估缓存新鲜度：
    • 如果原产国相同，则缓存键相同且ETag有效，返回未修改的HTTP 304
    • 如果原产国不同，缓存键也会不同，这样 ETag 无效，返回 HTTP 200 并返回新的 ETag。

同意Poul-Henning Kamp 的地理位置应该是运输层面的事情，但不幸的是不是，所以这是我们能想出的唯一方法来确保给定国家的缓存新鲜度。

缺点是不能有任何基础设施缓存，例如，所有请求都需要检查服务器的缓存新鲜度。

于 2013-08-20T09:34:34.887 回答