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.