Homepage cache and cookies

I am trying to cache the home page to a site. I am only caching the home
page. If I put in a condition to check for cookies existing before
caching,
everything works as expected, but there is a high BYPASS rate due to the
client not having the cookies the first time they visit the site. Once I
took out the check for cookies, clients started getting cached cookies
from
other users. Is there a way to still have the cookies set from the
origin
server, and have a cache hit?

server {
listen 80;

if ($request_uri !~* "home.html") {
            set $skip_cache 1; }

location / {
    proxy_pass http://backend;
    proxy_set_header Host      $host;
    proxy_cache_bypass $skip_cache;
    proxy_no_cache $skip_cache;
    proxy_pass_header Set-Cookie;
    proxy_cache one;
    proxy_cache_key

$scheme$proxy_host$uri$is_args$args$cookie_myCookie$cookie_myOtherCookie;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_ignore_headers “Set-Cookie” “Cache-Control” “Expires”;
proxy_hide_header “Set-Cookie”;
proxy_cache_lock on;
if ($http_user_agent ~*
‘(iPhone|Android|Phone|PalmSource|BOLT|Symbian|Fennec|GoBrowser|Maemo|MIB|Minimo|NetFront|Presto|SEMC|Skyfire|TeaShark|Teleca|uZard|palm|psp|openweb|mmp|novarra|nintendo
ds|hiptop|ipod|blackberry|up.browser|up.link|wap|windows
ce|blackberry|iemobile|bb10)’ ) {
proxy_pass http://backend_mobile; }
if ($http_user_agent ~* ‘(iPad|playbook|hp-tablet|kindle|Silk)’
) {
proxy_pass http://backend_tablet; }

    root   /opt/rh/rh-nginx18/root/usr/share/nginx/html;
    index  index.html index.htm;
}

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265629,265629#msg-265629

The proxy_cache_key defines which key differentiate any cache object. By
using $cookie_name in the string, the value of the cookie ‘name’ will
be
taken as part of the key.
If multiple clients have the same combination of variables value
(specifically, for cookie, presence, no presence or same value-s), they
will grab the same object from the cache. If different content might get
produced/grabbed with the same value in variables, then you have a
problem.

As a sidenote, you are using proxy_pass_header Set-Cookie with
proxy_hide_header Set-Cookie, which conflict one with each other. Remove
them altogether.

B. R.

On Thu, Mar 24, 2016 at 2:14 PM, john_smith77
[email protected]

Thanks for the info. I have removed the redundant config. I suppose what
I
am really getting at is that I would like Set-Cookie to never be cached
with
a cache MISS so that the cached cookie values are then not there for
subsequent HITS.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265629,265645#msg-265645

Indeed, but that prevents all cookies from being set. What I am looking
for
is to have a cache hit, but have the set-cookie served from the origin
server. In Apache httpd cache, this can be accomplished with
CacheIgnoreHeaders Set-Cookie.

The back end server here is Apache and I have tried setting it to send
back
this header:

Cache-Control:no-cache=“set-cookie”

There just does not seem to be a combination of options for nginx that
allows this to work.

I’ve tried this in nginx both with scenarios:

nginx -> Apache httpd -> wordpress
nginx-> Apache httpd -> tomcat

In both cases, proxy_hide_header will prevent the cookies from ever
being
set.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265629,265652#msg-265652

So I found a solution and it seems like there is unexpected behavior
from
nginx. proxy_hide_header Set-Cookie does not seem to work when the
location
block is set to /

So:

location / {
#Lots of other proxy stuff here…
proxy_hide_header “Set-Cookie”; }

does not allow a cookie to ever be set, but:

location ~home.html {
#Lots of other proxy stuff here…
proxy_hide_header “Set-Cookie”; }

will allow cache HITS but won’t cache Set-Cookie headers. Clients are
still
able to get the cookies from the back end and will never get another
users
session cookies.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265629,265658#msg-265658

That seems to match what the docs for proxy_hide_header
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header
states, just do not use proxy_pass_header at the same time… which does
the exact opposite.

B. R.

On Thu, Mar 24, 2016 at 9:31 PM, john_smith77
[email protected]

Hello John!

I think you can do this better with sessions in NginX.

I’ve made a script that checks if a client is a bot or not,
by testing if the Google Analytics cookie is here, or not.

If it is, the client can post a comment or login. If not, the
server is giving a fake page.

In my PHP script :


$host = $_SERVER['REMOTE_ADDR'];
$session_id = session_id();
$session_name = session_name();
[]
    if ( '' == $session_name ) {
      $session_name = '0';
      session_start();
      echo '<html><head></head><body><h1>server busy, come back 

later!’;
exit();
}
[]


All pages are cached :wink:

Regards,

Ph. Gras
Le 25 mars 2016 22:33, john_smith77 [email protected] a
crit :

Specifically I was writing that clients could get their cookies, but not
served form the nginx cache. This has always been about whether or not
the
cached page was serving the cookies or not.

With the exact same configuration for the cache, there is a difference
between:

location /

and

location /~home.html

in regards to whether or not the cached version of the page has the
Set-Cookie headers in it.

I will try and research some more to see if that would be expected or
not.

Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,265629,265686#msg-265686

Make sure you test this unexpected behavior with a minimal, reproducible
configuration.
If you succeed, please share it or (even better!) fill a bug report
https://trac.nginx.org/. Otherwise, that meant you probably did
something
Wrong.

​You were previously saying proxy_hise_headers did not pass cookies to
the
client. Now yo uare saying clients are able to grab their cookie.
I am a bit confused, here…​

B. R.

On Fri, Mar 25, 2016 at 10:33 PM, john_smith77
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs