使用 FastCGI 的 SSI 子请求的缓存键错误 [英] Wrong cache key for SSI-subrequests with FastCGI

问题描述

当我使用 SSI 时，NGinx 为子请求使用了错误的缓存键

When I use SSI, NGinx uses the wrong cache key for the subrequest

fastcgi_cache_key       "$request_method $scheme://$host$uri";

问题是，它以无限递归结束，因为在主请求中，NGinx 将包含 SSI 元素的页面存储在其缓存中，然后当它触发子请求时，使用此页面(包括 SSI 元素)) 作为子请求的结果(依此类推).我认为 $uri 正是为了避免这种情况而设计的(与 $request_uri 不同)，但显然它不起作用.

The problem is, that it ends up in an infinite recursion, because on the main request NGinx stores the page including the SSI-element in its cache and then when it triggers the subrequest, uses this page (including the SSI-element) as result of the subrequest (and so on and so on). I thought $uri is exactly designed to avoid this (unlike $request_uri), but obviously it doesn't work.

nginx 版本为 1.3.8

nginx version is 1.3.8

推荐答案

一个稍长的调试会话(nginx 调试日志...很大)给了我答案:它不是直接的缓存键，而是默认情况下，/etc/nginx/fastcgi_params 中的 REQUEST_URI 设置为 $request_uri.缓存键是正确的，但请求始终与父页面相同，因此父页面被缓存两次:一次用于 parent-uri-key，一次用于 ssi-subrequest.在每次后续调用中，都会使用(损坏的)缓存值.

A slightly longer debug-session (the nginxs debug-logs are ... big) gave me the answer: It was not the cache-key directly, but by default the REQUEST_URI is set to $request_uri in /etc/nginx/fastcgi_params. The cache key is correct, but the request is always identical to the parents one, so the parent page is cached twice: Once for the parent-uri-key and once for the ssi-subrequest. On every subsequent call the (broken) cached values is used.

fastcgi_param REQUEST_URI $uri;

这篇关于使用 FastCGI 的 SSI 子请求的缓存键错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！