We use the Clear-Site-Data header for cleaning cookies and other data on logout.
If this header is delivered with the response at https://example.com/clear-cookies, all cookies on the same domain https://example.com and any subdomains (like https://stage.example.com, etc), will be cleared out.
Now this is a problem, if other systems run on subdomains.
I also wonder what happens for domains like "example.co.uk" - would that mean that all the data for all UK company domains is cleared?
How does the browser determine which domains to clear? And can it be influcened?
We want to use it on oursystem.example.org so that it clears only oursystem.example.org and not othersystem.example.org
After looking into the w3c specification it seems like the Clear-Site-Data will clear only the specified domain including it subdomains. So if you clear example.co.uk it will also clear system.example.co.uk. If you clear anothersystem.example.co.uk it will also clear a.anothersystem.example.co.uk and all its subdomains. Here is the example that helped me understand it.
So if you clear oursystem.example.org it will have NO effects on othersystem.example.org but it will have effects on a.oursystem.example.org.
Related
Is there a way of forcing Google Analytics to combine variations of the same domain so it treats all subsequent visits from one user to any of these URLs as the same user? Here's an example:
http://www.example.com/mypage.php
https://www.example.com/mypage.php
http://example.com/mypage.php
https://example.com/mypage.php
What I hope to achieve is a setup where if a single user clicked each of these links, the results would appear in Analytics as:
http://www.example.com/mypage.php - Pageviews: 4 Users: 1
This question expands on this one from earlier
As I understand it, if I were to add a global 301 redirect to my .htaccess file, the user would be automatically redirected to whatever domain I specify. Is this the best solution?
The answer you linked to is outdated (if it was ever right). If you use Universal Analytics and set the cookie domain parameer to auto (which is the default) the cookie will be set for the domain and all subdomains:
Automatic Cookie Domain Configuration simplifies cross domain tracking
implementations by automatically writing cookies to the highest level
domain possible when the auto parameter is used. When used on the
domain www.example.co.uk, it will try to write cookies in the
following order:
co.uk
example.co.uk
www.example.co.uk
(see documentation). So you will have a cookie for example.co.uk on both domain and www subdomain which is valid for both.
Having said that, you should still use the 301 for SEO reasons (to avoid duplicate content, plus Google announced last year that ssl is a ranking factor now so you might want to use your https pages only).
I have a Concrete5 site which already has a bunch of contents and I want to point the images to my cookieless domain without replacing the urls.
I created an htaccess that will redirect all images from my main site to the cookieless domain
http://www.example.com/images/header.jpg
to
http://static.example.com/images/header.jpg
It's actually working but YSlow doesn't seem to honor this. It's still giving me a low score on that part.
Since you didn't change the image links, browsers will still make a request to the original URL and will send the cookies. That's probably why YSlow is still giving you a poor score for that.
To properly change it you would need to:
Change all links to the new cookie-less domain (static.example.com)
Change cookies to be issued for www.example.com only (per Croises comment above)
Remove the redirects for images
It's a lot of work to achieve, and depending on your site traffic it may not be worth it. Like all YSlow rules (and those from other tools), it's important to understand the recommendations. Not all of them are worth the effort for all websites.
Reference: Cookie-less domains best practices
I've read lots about what can be done with mod_rewrite but I haven't found one to solve my problem. Maybe it can't be done?
I have a sub-domain on my primary domain that I have a customer direct user to to use one of my programs. The customer doesn't want his customers to see that that are on my domain and he doesn't want to use an iframe.
So, is it possible for the user to only see www.subdomain/program.php instead of www.subdomain.mydomain.com/program.php?
If you want the browser to show www.subdomain/program.php in its location bar, you need to register the www.subdomain domain name. There is no way to remove bits of the domain name using anything in the htaccess file. For example, if you've registered example.com and you have a server at foo.example.com, and you want to be able to go to http://foo/some/path/index.html, you're out of luck because the browser is going to attempt to do a DNS lookup of foo and it will most likely fail unless there happens to be a "foo" server under the DNS search domain. Browsers put a great deal of effort to prevent spoofing of the domain name, since it would be really bad if I was able to spoof my website to show the domain of a bank in a browser's location bar while actually visiting an entirely different website.
I wanted to ask what is the best strategy for this situation:
We have a site example.de and we are launching a dedicated version of it for the Austrian market. Since both .de and .at sites use german language at the first few months we are going to show the same content in both sites (both domains point to same servers which choose what to show dynamically). Will this penalize our rankings because of duplication (and how can we tell google that "at is a copy for the de site").
In a month or two, .at users will start to see exclusive content for their region (though some parts of the site will stay the same).
Since we are not trying to cheat or smth else, how can we ensure google doesn't falsely penalize us?
Thanks
If you are going to show same content on both domains than I would suggest to redirect one domain to another one otherwise It will be considered duplicate content and eventually you will lose something.
You can use 302 for redirecting which does a temporary redirection, or
You can use 301 for permanent redirection which tells google that content has moved permanently to other domain.
But if you are planning to keep different content on both domains after a few months than I would say go with 302 redirect.
And if you are putting same content on example.de and example.au that will not impose any serious problems because you have different tlds with same second level domain.
But if you put same content on example.com and something.com than there will be some serious duplicate content problem.
But a much better approach would be to do something like this example.com/us , example.com/au , example.com/uk etc for countries or example.com/en , example.com/fr etc for languages.
my company is running IIS and DNN (I'm not a server guy, so color me ignorant), and I've read previous that you should either redirect your .http://www.mydomain to .http://mydomain or Vice Versa. Can anyone give me reasons to do this? (periods "prepended" to remove href)
From what I understand, it's because search engines see those as two different 'sites' (Even when visiting one or the other, I can be logged into one but not the other).
I also heard it can be a duplicate content problem, which search engines dislike.
Just looking for some professional insight, will help me and others.
Thanks!
This allows your site to be more SEO-friendly. Search engine crawlers will view these as two different URLs. That will cause your site's ranking in search engines to have multiple rankings for the same content.
ScottGu describes the problem and how to go about fixing it in a blog post:
http://weblogs.asp.net/scottgu/archive/2010/04/20/tip-trick-fix-common-seo-problems-using-the-url-rewrite-extension.aspx
Although it's mostly for SEO, there is also a potential usability issue in that a user who logs in on www.domain.com may get cookies that only work on the www subdomain and will be forced to log in again if they ever follow a link to domain.com (without the www prefix).
In addition to the SEO-friendlyness this also prevents some errors that might come up when both, with and without www works.
for example a user could login on www.yourdomain.com and would receive a cookie. later he visit your site via yourdomain.com and the cookie would not apply there.