我很困惑......关于这个和这个“元”问题...
一个非常基本的http请求：
GET http://stackoverflow.com/feeds/tag?tagnames=c%23&sort=newest HTTP/1.1
Host: stackoverflow.com
Accept-Encoding: gzip,deflate
它击中了用以下修饰的路由：
[OutputCache(Duration = 300, VaryByParam = "tagnames;sort",
VaryByContentEncoding = "gzip;deflate", VaryByCustom = "site")]
重复 和如果您包含 if-modified-since，则错误地提供 304（无变化），或者错误地提供 200 的旧数据，即
HTTP/1.1 200 OK
Cache-Control: public, max-age=0
Content-Type: application/atom+xml; charset=utf-8
Content-Encoding: gzip
Expires: Fri, 01 Jul 2011 09:17:08 GMT
Last-Modified: Fri, 01 Jul 2011 09:12:08 GMT
Vary: *
Date: Fri, 01 Jul 2011 09:42:46 GMT
Content-Length: 14714
(payload, when decoded = some long-stale data)
如您所见，它正在提供这比 5 分钟时段快了半个小时；看起来 OutputCache 的内部结构根本没有注意到时间；p 它最终会过期（事实上，它刚刚这样做了 - 我的 Fri, 01 Jul 2011 09:56： 20 GMT 请求终于得到了新鲜数据），但并不像任何地方都准时。
更新：
我相信如果我们去掉接受编码标头，它就会起作用，但事实并非如此；这也失败了 - 它只是在不同的周期失败（这是我们应该期望的，因为密钥不同，由 VaryByContentEncoding 提供）：
GET http://stackoverflow.com/feeds/tag?tagnames=c%23&sort=newest HTTP/1.1
Host: stackoverflow.com
给出：
HTTP/1.1 200 OK
Cache-Control: public, max-age=0
Content-Type: application/atom+xml; charset=utf-8
Expires: Fri, 01 Jul 2011 10:09:58 GMT
Last-Modified: Fri, 01 Jul 2011 10:04:58 GMT
Vary: *
Date: Fri, 01 Jul 2011 10:17:20 GMT
Content-Length: 66815
(payload = some stale data)
再一次，您会注意到它正在被提供 < em>之后 过期。
那么：这里可能出了什么问题？
额外的;当我们使用自定义选项时，我们的 GetVaryByCustomString() 会根据 base.GetVaryByCustomString(ctx, custom) 来获取它无法识别的选项“http://msdn.microsoft.com/en-us/library/5ecf4420.aspx”rel="nofollow noreferrer">MSDN（事实上，这对于第二个上面的例子）。
I'm flumoxed... re this and this "meta" questions...
A very basic http request:
GET http://stackoverflow.com/feeds/tag?tagnames=c%23&sort=newest HTTP/1.1
Host: stackoverflow.com
Accept-Encoding: gzip,deflate
which hits a route decorated with:
[OutputCache(Duration = 300, VaryByParam = "tagnames;sort",
VaryByContentEncoding = "gzip;deflate", VaryByCustom = "site")]
is repeatedly and incorrectly serving either a 304 (no change) if you include if-modified-since, or the old data for a 200, i.e.
HTTP/1.1 200 OK
Cache-Control: public, max-age=0
Content-Type: application/atom+xml; charset=utf-8
Content-Encoding: gzip
Expires: Fri, 01 Jul 2011 09:17:08 GMT
Last-Modified: Fri, 01 Jul 2011 09:12:08 GMT
Vary: *
Date: Fri, 01 Jul 2011 09:42:46 GMT
Content-Length: 14714
(payload, when decoded = some long-stale data)
As you can see, it is serving this nearly half an hour past the 5 minute slot; it looks like the internals of OutputCache simply didn't notice the time ;p It will expire eventually (in fact, it has just done so - my Fri, 01 Jul 2011 09:56:20 GMT request finally got fresh data), but not anywhere like punctually.
UPDATE:
I believed that it was working if we took away the accept-encoding header, but no; this fails too - it just fails on a different cycle (which is what we should expect since the keys are different, courtesy of VaryByContentEncoding):
GET http://stackoverflow.com/feeds/tag?tagnames=c%23&sort=newest HTTP/1.1
Host: stackoverflow.com
gives:
HTTP/1.1 200 OK
Cache-Control: public, max-age=0
Content-Type: application/atom+xml; charset=utf-8
Expires: Fri, 01 Jul 2011 10:09:58 GMT
Last-Modified: Fri, 01 Jul 2011 10:04:58 GMT
Vary: *
Date: Fri, 01 Jul 2011 10:17:20 GMT
Content-Length: 66815
(payload = some stale data)
Once again, you'll notice it is being served after Expires.
So: what could be wrong here?
Additional; while we are using a custom option, our GetVaryByCustomString() correctly calls base.GetVaryByCustomString(ctx, custom) for options it doesn't recognise, as per MSDN (indeed this works fine for the second example above).
发布评论
评论（1）
您是否有可能使用自定义输出缓存提供程序？ 假设，如果有一个自定义提供商使用滑动到期而不是绝对到期，您会看到类似这样的症状。
Is there any chance you're using a custom output cache provider? Hypothetically, if there was a custom provider using say a sliding expiration instead of an absolute one, you'd see symptoms like this.