Fastcgi_cache Key Length Bug

[cromulus]

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