WordPress.org

Ready to get started?Download WordPress

Forums

Cookieless setting for non-www domain (19 posts)

  1. Rajasekharan N
    Member
    Posted 3 years ago #

    Currently there seems to be no option for a cookieless subdomain for your WordPress site if you have preferred a non-www URL as expressed here.

    Can anything be done in this regard in the future versions of WordPress so that a cookieless subdomain can be created for a non-www WordPress blog also?

  2. How are you making WP be cookie less right now?

    Most people redirect www to non-www (or vice versa) which means you only have to handle it once.

  3. Rajasekharan N
    Member
    Posted 3 years ago #

    Current I add this code to the code to wp-config.php: define('COOKIE_DOMAIN', 'www.yoursite.com');

    But if your site is a non-www, this wouldn't allow you to log in to your admin panel if your browser cookie expires. Then you have to again FTP the wp-config.php file without this line and log in to your admin panel. After logging in, again FTP the wp-config.php file with this code included. It's a headache. Just putting yoursite.com or .yoursite.com in the code will not do the trick as it will again create cookies in any subdomain.

  4. Why are you defining it at all?

  5. Rajasekharan N
    Member
    Posted 3 years ago #

    The ultimate aim of a cookieless subdomain is to ramp up speed according to Google/Yslow Page Speed requirements. One of the requirements of Page Speed is to serve static contents like images and stylesheets from a cookieless domain/subdomain. After meeting all the requirements including serving images from a cookieless domain and solving all the errors pointed out by Google Page Speed, I was able to bring down the page speeds from 12 seconds to 1+ seconds for my site MT Herald. Currently its Page Speed score is 100/100 and YSlow grade is A. WordPress by default sets up cookies in all subdomains in its neighborhood even if you serve static contains from subdomains like images.yoursite.com. However, WordPress has this option to define a cookie domain so that it would leave other subdomains intact without cookies.

    But again, in my case moving to www URLs would solve the purpose. However, my prime aim of speed will get affected with every URL on the web pointing to my site getting redirected with a 302.

    Hence at present the only viable solution that I could find is to define a cookie domain as accepted by WordPress as mentioned above and to set the expiry date of the cookies for an admin by a year so that it would allow to log in to the admin dashboard. So the purpose is solved; WordPress won't create cookies at the user end browser for the contents from the cookieless subdomain and the administrator will be able to log in to the dashboard.

    If you are still blank about what I said in detail here, I urge you to again read this page which I mentioned right at the beginning.

    Hope some hard core, knowledgable WordPress coder sees this discussion and comes up with a permanent solution.

  6. I read it, but I think you're doing it wrong. (And thank you so very much for the implication that I'm not knowledgeable. That really makes my morning.)

    WordPress needs cookies so that you can retain login info, as you well know. Unless you're the EU having a snit fit, cookies are good in this case. Users are remembered by their browser, everyone's happy. This is true, by the way, of all web apps, like WordPress, Drupal, Joomla, ZenPhoto, etc etc.

    One of the requirements of Page Speed is to serve static contents like images and stylesheets from a cookieless domain/subdomain.

    Not a requirement, but a SUGGESTION, just be be clear on that one.

    http://code.google.com/speed/page-speed/docs/request.html#ServeFromCookielessDomain

    Even there, however, they suggest a separate domain, not a subdomain. That's why places like Amazon CDN and others use a separate domain named something OTHER than amazon.com - Full separation. For one reason, it prevents the cookie issue you're seeing, but for another, it separates the content clearly.

    If you want to host your own CDN, you should get another domain (like yoursitecdn.com) and put the data there. It won't incur that much extra cost in the long run, and solves your issue by following the recommended practice.

    Wanna have fun? Go look at how Amazon puts cookies down on your desktop. .amazon.com That would cover all their subdomains too.

    What you're doing has a point, but you're running into a flaw not with WordPress, but with the basic expectation of how webservers in general run, and how web browsers talk to them. Since that's going to be a loosing battle, do best practice and get a CDN on it's own domain. After all, WordPress uses http://s2.wp.com for a reason.

  7. Rajasekharan N
    Member
    Posted 3 years ago #

    I appreciate your suggestion of a CDN or separate domain for just a few bucks.

    But how about a very small site that has excessive bandwidth? That same link you have referred says

    (For pages that serve fewer resources than this, it's not worth the cost of setting up an extra domain.)

    And sorry for that "knowledgable" tease. Just read your profile which says

    Pestering me just sets things to prolapse
    and hence had to!

    Meanwhile I have come up with a post on How to optimize a WordPress blog for better Page Speed. I welcome your thoughts.

  8. The prolapse is cause I like Spider Jerusalem and Transmetropolitan (which if you've not read, it's awesome).

    But how about a very small site that has excessive bandwidth?

    I would pay for an external CDN like Amazon, or MaxCDN. Or if possible, optimize the hell out of my server, install caching, and let it run and get 90 on my pagespeed until I can afford/justify paying more.

    Doesn't matter how big or small the site is, what matters is the traffic. If you're gonna get hit, you have to step up and pay to keep it up, or ... y'know, suffer.

    I also don't think that pagespeed is the be-all and end-all of a measure of how 'good' a site is. There's 100/100 and there's fast enough.

  9. Rajasekharan N
    Member
    Posted 3 years ago #

    WordPress caching has less significance on a LiteSpeed server.

    Instead of going for a CDN, I employed all those tricks including "cookieless" subdomain to reach that 100. However, the interesting part is that even after defining a www cookie domain, WordPress still makes cookies on the first view for the contents from the subdomain. Only from the second view onwards, it becomes cookieless.

    Okay, let me drive home the point clear again. If anybody can help me in "defining a cookieless domain" rather than defining a cookie domain, I will be very much grateful.

  10. It's not a WordPress problem, which was my point. It's how domains and cookies work.

    http://www.phpied.com/www-vs-no-www-and-cookies/

    You have to use www

  11. Samuel Wood (Otto)
    Tech Ninja
    Posted 3 years ago #

    What you're trying to do is not actually possible. You can't set cookies for the "root" domain and not have them go to subdomains as well. This isn't a WP issue at all, it's simply how cookies work.

    If you want to use a subdomain for static caching (and I have seen this done many times), then you should define the "main site" on a subdomain too.

    In other words, you have to have the www for such a case. Set the cookie domain to the www domain and it'll only set cookies for that. Not for the root domain.

  12. Rajasekharan N
    Member
    Posted 3 years ago #

    Okay. Now it's clear. The only permanent solution left back is to convert the domain into www.

    Thanks Ipstenu and Otto for making that crystal clear.

  13. Samuel Wood (Otto)
    Tech Ninja
    Posted 3 years ago #

    Oddly enough, this sort of behavior is a quirk. The final definitive specification of cookies *does* offer a way to do this sort of thing, but no user-agent implements it this way.

    Mainly because this final spec only came out this April.

    In that spec, you'll find this:

    If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.

    WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name. For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to http://www.example.com as well.

    In other words, if you omit the domain, a browser should allow it to be sent to only the main domain and not subdomains. No existing browser behaves this way.

  14. Rajasekharan N
    Member
    Posted 3 years ago #

    Okay, I cannot benefit even if I define an empty domain like this with the current browsers: define('COOKIE_DOMAIN', '');

    The other doubt that I have now is "Can I define the cookie domain like the ones below which will allow me to log in to the admin panel?" Of course, the WordPress files have to be in the "blog" folder in the root domain.

    1.) define('COOKIE_DOMAIN', '.yoursite.com/blog');

    2.) define('COOKIE_DOMAIN', 'yoursite.com/blog');

    3.) define('COOKIE_DOMAIN', '.blog.yoursite.com');

    4.) define('COOKIE_DOMAIN', 'blog.yoursite.com');

    I welcome your thoughts in this regard.

  15. Ron Rennick
    MultiSite Guru
    Posted 3 years ago #

    You can't have the path in your COOKIE_DOMAIN. But for the original question if you

    define('COOKIE_DOMAIN','yoursite.com');

    browsers will not use the cookie for the subdomains (not even the www).

  16. Rajasekharan N
    Member
    Posted 3 years ago #

    But how to log in to admin dashboard then? It needs cookies to log in to admin panel.

  17. If you do that, then login at yourdomain.com/wp-admin

    The cookie (apparently) will be writ JUST for yourdomain.com ... which is surprising news to me!

  18. Samuel Wood (Otto)
    Tech Ninja
    Posted 3 years ago #

    Ron: I would want to test that in multiple browsers, because the latest spec (RFC 6265) actually says otherwise.

    5.1.3. Domain Matching

    A string domain-matches a given domain string if at least one of the
    following conditions hold:

    o The domain string and the string are identical. (Note that both
    the domain string and the string will have been canonicalized to
    lower case at this point.)

    o All of the following conditions hold:

    * The domain string is a suffix of the string.

    * The last character of the string that is not included in the
    domain string is a %x2E (".") character.

    * The string is a host name (i.e., not an IP address).

    In other words, if I define a cookie at example.com, then go to http://www.example.com, then the following holds:

    - The domain string (example.com) is a suffix of http://www.example.com. Check.
    - The last character of the string not in the domain string (example.com) is a period. Check.
    - The string is a hostname. Check.

    So http://www.example.com *should* receive the cookie. Some browsers may or may not do this.

    The latest spec may or may not be valid in browsers, I admit. Previous specs that specified a dot at the beginning of the domain string for subdomains are not the case anymore. In fact, having a dot at the front of the domain is actually invalid, but ignored.

    4.1.2.3. The Domain Attribute

    The Domain attribute specifies those hosts to which the cookie will
    be sent. For example, if the value of the Domain attribute is
    "example.com", the user agent will include the cookie in the Cookie
    header when making HTTP requests to example.com, http://www.example.com, and
    http://www.corp.example.com. (Note that a leading %x2E ("."), if present,
    is ignored even though that character is not permitted, but a
    trailing %x2E ("."), if present, will cause the user agent to ignore
    the attribute.)
    If the server omits the Domain attribute, the user
    agent will return the cookie only to the origin server.

    WARNING: Some existing user agents treat an absent Domain
    attribute as if the Domain attribute were present and contained
    the current host name. For example, if example.com returns a Set-
    Cookie header without a Domain attribute, these user agents will
    erroneously send the cookie to http://www.example.com as well.

  19. Rajasekharan N
    Member
    Posted 2 years ago #

    This has become very interesting and very useful discussion indeed, and I want to share with you guys the interesting part of my research.

    1) I moved just the DNS hosting elsewhere, (CloudFlare for free), separate from the host.
    2) By doing so, sometimes (not always) the images are served from one IP and the contents from another IP, something similar to CDN, which is at the mercy of DNS hosting provider.
    3) I have my images at images.mysite.com and my main site is a non-www.
    4) I removed the code define('COOKIE_DOMAIN', 'www.yoursite.com'); from my wp-config.php, and I have nothing defining about the cookies there now.
    5) At the backend, I am able to log in to my admin panel.
    6) At the front end, just for the first view cookies are getting created for the images and from the second view onwards cookies are not getting created for the images.
    7) I tested this using Firefox/Firebug.

    Seems to be an amicable solution. Just to make it sure again with you coders a quick question: Am I becoming cookieless at the mercy of my DNS host or is it because of something that I messed up? What are your comments?

Topic Closed

This topic has been closed to new replies.

About this Topic