如何评估 Kohana 3.2 HTTP_Cache 缓存请求中的 ACL
最近升级到基于内部 K3.2 REST 的 API 后，我正在考虑利用内部请求缓存机制。
我正在研究初始请求级别的缓存（因此在应用程序index.php中）：
1）这是一个根本上有缺陷的想法吗？
我的初始请求如下所示：
$obj_r = Request::factory(TRUE, HTTP_Cache::factory('memcache'))
->execute();
echo $obj_r->send_headers()
->body();
这一切都很好，除了从与内部 basic_cache_key_generator 匹配的源发出的请求将简单地（正确地）返回缓存的响应 - 跳过任何应用程序 ACL 规则（通常作为父级的一部分发生： before 函数
2) 这里提供自定义的 cache_key_callback 作为 HTTP_Cache::factory 调用的选项是正确的方法吗？ - 在这个自定义回调中，我可以构建并评估 ACL 规则，如果需要的话，拒绝访问资源
如果我错过了与此相关的任何文档，我深表歉意，我已经看过了！
After a recent upgrade to an in-house K3.2 REST based API I'm looking at making use of the internal request caching mechanism.
I'm looking at caching at the initial request level (so within the application index.php):
1) is this a fundamentally flawed idea?
My initial request looks like this:
$obj_r = Request::factory(TRUE, HTTP_Cache::factory('memcache'))
->execute();
echo $obj_r->send_headers()
->body();
This all works great, except that requesting from a source that matches the internal basic_cache_key_generator will simply (and correctly) return the cached response - skipping any application ACL rules (which normally occur as part of a parent ::before function
2) Is the correct approach here to provide a custom cache_key_callback as an option to the HTTP_Cache::factory call? - within this custom callback I can then build and evaluate the ACL rules denying access to the resource if required
Sincere apologies if i've missed any docs relating to this, I have looked!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你应该使用
$this->response->check_cache($cache_key, $this->request)。您的页面将根据该自定义回调发送 ETag。I think you should use
$this->response->check_cache($cache_key, $this->request)instead. Your page will send ETag based on that custom callback.