I’ve been trying to set up two separate proxy caches, one for logged in
users, one for guests. The one for guests had a very long expiry as
guest pages don’t change much, User pages are very dynamic and expiry is
very short.
Using cookies i can tell if a page request is by a user or guest, but I
cannot see any easy way to alter the proxy as all the proxy_cache
commands can’t be put inside an if.
I’ve managed the following workaround, which works fine but it seems
strange i have to use this method when there must be an easier and more
straightforward way that i am just not seeing
set $memcached_key “pages:$uri:$cache_key”; ### dummy key, will never
exist as i’m not using memcache for nginx
if ($cache_key = “guest”){error_page 404 = @guests;} #set 404 for quest
if ($cache_key != “guest”){error_page 404 = @users;} #set 404 for users
memcached_pass 127.0.01:11220; ## this server is empty, has no keys will
ALWAYS return 404
On Wed, Sep 01, 2010 at 03:00:30PM -0400, paul2791 wrote:
strange i have to use this method when there must be an easier and more
straightforward way that i am just not seeing
set $memcached_key “pages:$uri:$cache_key”; ### dummy key, will never
exist as i’m not using memcache for nginx
if ($cache_key = “guest”){error_page 404 = @guests;} #set 404 for quest
if ($cache_key != “guest”){error_page 404 = @users;} #set 404 for users
memcached_pass 127.0.01:11220; ## this server is empty, has no keys will
ALWAYS return 404
Alternatively you may want to just set correct Cache-Control /
Expires / X-Accel-Expires headers in backend’s response and avoid
explicitly setting validity via proxy_cache_valid.
Maxim,
Thats brilliant, thanks
Would proxy_pass be considered as a rewrite and safe within an IF as i
use it a lot to bypass cache?
Also, 418 is great code, had never seen that before. I do have some
logic elsewhere in my conf where i have more than two ifs. Does Nginx
allow the use of nondefined codes? 419 for instance? so i could have
Ive got as far as testing the error_page 419 =@cache2 ; line and nginx
didn’t choke on that, but haven’t tested the actual return yet
And yes, all of this would be easier of the developers set expires in
backend, but until they do, im using nginx to make sure our site flies
as fast as it can no matter how slow their code is
On Thu, Sep 02, 2010 at 11:15:14AM -0400, paul2791 wrote:
I just tried a quick test, using your first method for users/guests ,
with 419 instead of 418. Seems to work fine. Any reason I couldn’t or
shouldn’t use these codes to redirect to different interal @locations???
418 is one from RFC 2324, “Hyper Text Coffee Pot Control
Protocol”. It means “I’m a teapot”. Good code to say request
should be processed elsewhere.
You are free to use any 4xx/5xx code otherwise unused in a
particular location (and it’s good idea to avoid overloading codes
which may happen to be returned due to other reasons).
I just tried a quick test, using your first method for users/guests ,
with 419 instead of 418. Seems to work fine. Any reason I couldn’t or
shouldn’t use these codes to redirect to different interal @locations???
418 is one from RFC 2324, “Hyper Text Coffee Pot Control
Protocol”. Â It means “I’m a teapot”. Â Good code to say request
should be processed elsewhere.
Isn’t that non-canonical? it’s for coffee machines, not for normal
servers or proxies.
(Only joking, I guess the Internet won’t stop working because of this
non standard usage)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.