Fastcgi_cache Key Length Bug

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:

http://example.com/wp-admin/load-scripts.php?c=1&load=admin-bar,hoverIntent,common,jquery-color,wp-ajax-response,wp-lists,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-resizable,quicktags,jquery-query,admin-comments,jquery-ui-sortable,postbox,dashboard,thickbox,plugin-install&ver=f8890f4269ea35a6d5e30382070f0a89

using this key:

fastcgi_cache_key $host$request_uri$request_method;

fastcgi backend is php-fpm

system:
Ubuntu 9.04
kernel: 2.6.32.16
arch: i686

Thanks!
Let me know if there is any other info I can provide to help squash this
bug!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,188949,188949#msg-188949

On Wed, Apr 06, 2011 at 07:37:21PM -0400, cromulus wrote:

kernel: 2.6.32.16
arch: i686

Thanks!
Let me know if there is any other info I can provide to help squash this
bug!

nginx cache should work with keys up to ~65000 characters.
Could you test your setup without fastcgi_cache ?


Igor S.
http://sysoev.ru/en/

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.

In the meantime, one of these urls works, and the other doesn’t, the
difference being a single character:
http://alchemi.st/wp-admin/load-scripts.php?load=hoverIntent,common,jquery-color,schedule,wp-ajax-response,autosave,suggest,wp-lists,jquery-ui-core&foobar=asf
http://alchemi.st/wp-admin/load-scripts.php?load=hoverIntent,common,jquery-color,schedule,wp-ajax-response,autosave,suggest,wp-lists,jquery-ui-core&foobar=as

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.

Thanks again!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,188949,189116#msg-189116

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.

Sorry to bother you all!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,188949,189146#msg-189146

Igor and Maxim,

Thanks for your help!

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,188949,189442#msg-189442

Hello!

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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs