# Fastcgi\_cache Key Length Bug **URL:** \ **Category:** NGINX\ **Created:** [April 7, 2011, 1:37am UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457 "2011-04-07T01:37:42Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [April 7, 2011, 1:37am UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/1 "2011-04-07T01:37:42Z")
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](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: > **[Fastcgi\_cache Key Length Bug](https://forum.nginx.org/read.php?2,188949,188949#msg-188949)** > > 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,... ---
**Author:** ![cromulus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e5b9ba/32.png) [@cromulus](https://www.ruby-forum.com/u/cromulus)\ **Post date:** [April 7, 2011, 9:00am UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/2 "2011-04-07T09:00:21Z")
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. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![cromulus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e5b9ba/32.png) [@cromulus](https://www.ruby-forum.com/u/cromulus)\ **Post date:** [April 7, 2011, 4:00pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/3 "2011-04-07T16:00:38Z")
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=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](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/](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: > **[Re: Fastcgi\_cache Key Length Bug](https://forum.nginx.org/read.php?2,188949,189116#msg-189116)** > > 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,... ---
**Author:** ![cromulus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e5b9ba/32.png) [@cromulus](https://www.ruby-forum.com/u/cromulus)\ **Post date:** [April 7, 2011, 5:29pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/4 "2011-04-07T17:29:35Z")
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: > **[Re: Fastcgi\_cache Key Length Bug](https://forum.nginx.org/read.php?2,188949,189146#msg-189146)** > > 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,... ---
**Author:** ![cromulus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e5b9ba/32.png) [@cromulus](https://www.ruby-forum.com/u/cromulus)\ **Post date:** [April 8, 2011, 5:25pm UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/5 "2011-04-08T17:25:03Z")
Igor and Maxim, Thanks for your help! Posted at Nginx Forum: > **[Re: Fastcgi\_cache Key Length Bug](https://forum.nginx.org/read.php?2,188949,189442#msg-189442)** > > 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,... ---
**Author:** ![cromulus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e5b9ba/32.png) [@cromulus](https://www.ruby-forum.com/u/cromulus)\ **Post date:** [April 8, 2011, 3:45am UTC](https://www.ruby-forum.com/t/fastcgi-cache-key-length-bug/205457/6 "2011-04-08T03:45:52Z")
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.