Igor and Maxim, Thanks for your help!by cromulus - Nginx Mailing List - English
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!by cromulus - Nginx Mailing List - English
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 samby cromulus - Nginx Mailing List - English
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/lby cromulus - Nginx Mailing List - English
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/lby cromulus - Other discussion