fastcgi_cache_bypass and 502 Bad Gateway

Dayo nginx-forum at nginx.us
Sat Feb 12 12:15:48 MSK 2011


António P. P. Almeida Wrote:
-------------------------------------------------------
> So there's no concept of scope in the usual
> programming language
> sense. It just depends on the request. If the
> request visits all
> locations where variables are set, then the values
> are set
> independently of the context level at which the
> assignment
> instructions exist.
> 
> Is this correct?
I think this is correct but this to me essentially create a variable
scope since as Maxim has explained elsewhere, the if block creates a
nested location block and since only one location block is processed in
the request flow, things set in there may not be visible, to the rest of
the flow.

The problem is know what exactly is visible after and what is not.

So far, according to the ifisevil page, it seems 'return', and rewrite
commands are safe but anything else may result in errors.

It may be the case that 'set' is safe too and a list of what is and
isn't would be really great.

For me, I just use the two listed stuff on the ifisevil page (return and
rewrites) and agetnzh's lua module to do other if tests.

To the OP, perhaps try using the same variable on both fastcgi params
which from Maxim's explanation, is not susceptible to the bug.

fastcgi_no_cache   $http_cache_bypass; # do no cache at all
fastcgi_cache_bypass   $http_cache_bypass; # bypass cache <--- Not sure
how you get the user's browser to send this header

At a suitable point in your application, you could also do something
like
EQUIVALENT-OF if ($http_cookie ~*
"comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
  header(Cache-Control: private, no-store, no-cache);
}
so that nginx will not cache the response.

Basically, try to share the load between the application and nginx.

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




More information about the nginx mailing list