5

I just discovered that cookies for www and non-www are different. I now understand that the browser treats example.com and www.example.com as two different domains. In detail, how can I assure that cookies are the same for each?

I've tried

RewriteCond %{HTTP_HOST} ^www.example.org$
RewriteRule (.\*) http://example.org/$1 [L,R=301]

And AllowOverride All in <Directory /var/www/> in apache2.conf, but it doesn't seem to work.

2
  • What is the DocumentRoot? AllowOverride All should generally only be set for the document root directory in the appropriate vHost container. /var/www/ looks higher up the directory tree than it needs (should) be. But if you have access to the server config why are you using .htaccess for the canonical redirect?
    – MrWhite
    Commented Mar 5, 2021 at 19:08
  • yes, that's completely possible for all websites. If your site accessed via example.com and www.example.com, not both. They are different domains to browsers, which is why you are getting different data. You can also search for having the same content accessed by different URLs www.domain.com/home should not show the same data as domain.com/home.It is considered that spammy. You decide which you want to use www or non-www and then 301 direct all traffic to that one. just like you are going from HTTP to HTTPs in your config.
    – AjayGohil
    Commented Mar 11, 2021 at 7:09

1 Answer 1

2

This is arguably a problem with your server-side application and how you are setting cookies (if this behaviour is undesirable), rather than the browser per se. In order to set a cookie, you determine on what domain (or rather, what part of the current hostname) the cookie is set. If your application is setting two different cookies, one for the www subdomain and one for the domain apex, then it's setting the cookie on the requested hostname only, rather than the domain apex (and all subdomains).

However, redirecting from one to the other would workaround the issue since it obviously prevents the site being accessible from the non-canonical hostname and the application can't then set a cookie on it. (Note that browsers will continue to send the Cookie header on the non-canonical hostname, whilst it's still valid in the browser.)

If the non-www hostname is canonical then you should indeed be redirecting from www to non-www...

RewriteCond %{HTTP_HOST} ^www.example.org$
RewriteRule (.\*) http://example.org/$1 [L,R=301]

This is close, but you have a typo in the RewriteRule pattern that will prevent it from matching "most" URLs... (.\*) matches a literal *, which is probably not the intention. It should simply be (.*) to match "everything" (no backslash escape before the *).

You should also presumably be redirecting to HTTPS, not plain old HTTP? And if only have the one domain then you can simplify the condition to match just www at the start of the hostname, rather than matching the entire hostname.

For example:

RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) https://example.org/$1 [L,R=301]
5
  • Thanks for the reply. Unfortunately, after adding the example provided to .htaccess I'm still getting two sets of cookies, www and non-www.
    – Alan
    Commented Mar 5, 2021 at 18:49
  • What do you mean exactly by "still getting two sets of cookies"? Is it not redirecting? Where have you added that rule in .htaccess? Order is important - it would need to go near the top of the .htaccess file, if you have existing directives.
    – MrWhite
    Commented Mar 5, 2021 at 18:52
  • My site saves four user-selectable values into cookies. If I go to example.org and save values one set of cookies is saved. I go to www.example.org the values aren't returned from my previous visit, and what's more if I save values again Chrome reports cookies for example.org and www.example.org. The redirect is reporting as OK (redirect-checker.org). Your .htaccess is at the top of the file. I hope I was clear! Thanks again!
    – Alan
    Commented Mar 5, 2021 at 21:10
  • 1
    How do you go to www.example.org when you have configured it to redirect to example.org. Commented Mar 6, 2021 at 9:45
  • Yes, I'm wondering this as well. The redirect is meant to "workaround" this problem going forward. With the redirect (to non-www) in-place it's not possible for cookies to be set on the www subdomain by your backend application. Obviously, any cookies that were previously set on the www subdomain, before the redirect was implemented, will still remain until their natural expiry (as stated above) and you will still be able to see these if you examine the stored cookies in the browser. But these are no longer accessible to your application.
    – MrWhite
    Commented Mar 6, 2021 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.