When using fastcgi_cache, if the key you are using is too long, say over
255 characters, it appears that fastcgi_cache breaks, and you get errors
that look like this:
*18 upstream sent unsupported FastCGI protocol version: 114 while
reading upstream,
I’ve encountered this error in 0.8.54 and 0.9.7
this is an example of a url that will break fast_cgi cache:
Igor,
It was working as advertised before i setup the fastcgi_cache, using
just plain fast_cgi. In the process of trying to debug this, I turned
fast_cgi cache on and off, and that particular url worked when fast_cgi
cache was turned off.
In addition, extra long urls that normally would have produced a 404
before i implemented fast_cgi cache did not produce a 404, and instead
produced the same error mentioned above.
In performing more debugging, I realized that this only happens when the
request should bypass the cache, using fastcgi_cache_bypass.
I’m also using the nginx_cache_purge plugin, which I will disable, test
again, and report back to see if we can isolate this problem in that
particular plugin.
the error that I get is this:
[error] 4671#0: *17568 upstream sent unsupported FastCGI protocol
version: 97 while reading upstream,
Take a look here to see my exact configuration: http://alchemi.st/2011/04/05/nginx-wordpress-network-and-fastcgi-cache-the-ultimate-guide/
I added a specific section to the nginx config as a workaround to this
particular problem, however, without that workaround, the
load-scripts.php script fails, as does any sufficiently long url that
should bypass the cache.
What is baffling to me is that the wp-admin/load-scripts.php file should
bypass the cache, as I have the wp_logged_in cookie set.
I will try this without the nginx_cache_purge plugin and see how things
go.
Here is the problem: if the fastcgi_cache_bypass directive is below the
fastcgi_cache_key directive, you encounter this particular problem.
Moving the fastcgi_cache_bypass directive above the fastcgi_cache_key
directive solved the problem and now urls of any length are process
correctly.
On Thu, Apr 07, 2011 at 11:28:45AM -0400, cromulus wrote:
I figured it out.
Here is the problem: if the fastcgi_cache_bypass directive is below the
fastcgi_cache_key directive, you encounter this particular problem.
Moving the fastcgi_cache_bypass directive above the fastcgi_cache_key
directive solved the problem and now urls of any length are process
correctly.
I believe the problem in your case is not order of directives, but
fastcgi_cache_bypass itself. It has known problem that it doesn’t
work correctly (results in corrupted cache entries) unless the
same predicates are used in fastcgi_no_cache.
Maxim D.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.