fastcgi_cache_bypass and 502 Bad Gateway

[António P. P. Almeida]

On 12 Fev 2011 09h15 WET, nginx-forum at nginx.us wrote:

> 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

Hmm, IIRC I've read somewhere that (some?) fastcgi directives do
behave like a "standard" programming language thing in the sense
there's a scope and the usual rules apply. But I may be wrong. It
would be great if Igor, Maxim or agentzh could elaborate further and
help put this issue to rest, at least make it clear what's a hack, and
what's not hack, i.e., behaves much more in the declarative language
sense than in the imperative programming sense.

> 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.

Or send the 'X-Accel-Expire: 0' header.

--- appa