Django URLValidator will raise a validation error for this website URL because of the underscore:
http://beauharnois_bupa.tripod.com/
From what I've read some says that it's not a valid domain name, some say it is and the RFCs seems to say that it's legal in the subdomain label but not in the hostname.
My guess is that it is legal in the subdomain label since the website mentioned above works..
Who's right ?
Underscores are not valid characters, even in subdomains, so it will be marked as invalid. However, some sites that dynamically route requests based on a subdomain component do allow underscores, even though they're technically an invalid character. So you might be able to navigate to the URL, even though it's technically not valid.
RFC 1035 discusses the structure of a domain name.
according to Can (hostname) subdomains have an underscore "_" in it? it should be legal.
It is perfectly legal to have an underscore in a domain name. Let me quote the standard, RFC 2181, section 11, "Name syntax":
Related
What is the difference between local.test.com and .local.test.com ? The screenshot is from Chrome.
The leading dot means that the cookie is valid for subdomains as well; nevertheless recent HTTP specifications (RFC 6265) changed this rule so modern browsers should not care about the leading dot. The dot may be needed by old browser implementing the deprecated RFC 2109.
RFC 6265 section 4.1.2.3
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, www.example.com, and 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.)
local.test.com will be used for the domain, while .local.test.com will be used for subdomains too.
From the article The definitive guide to cookie domains and why a www-prefix makes your website safer:
Conclusion
Although the definitions are somewhat different, we can simplify it
for any of these implementations as:
When no domain is set in the cookie, the cookie should only match the
exact host name of the request. [NOTE: this is different from returning a Set-Cookie with a domain without a dot!] No sub domains, no partial matches.
This means simply not including the domain attribute – it is not valid
to set an empty domain attribute. Unfortunately, Internet Explorer
appears to treat this as the host name along with any subdomains.
When setting a domain in the cookie, the safe choice is to have it preceded
by a dot, like .erik.io. The cookie will match with all sub domains.
Setting a cookie domain without a preceding dot, like erik.io, is
invalid in RFC 2109 implementations, and will produce the same
behaviour as with a preceding dot on other implementations. There is
no way to restrict a cookie to a specific explicitly set domain,
without sub domains being included.
Other worthwhile observations:
In all RFCs, a specified cookie domain must match the current host
name, per normal matching. Setting a cookie for www.erik.io in a
response from erik.io is not valid, as a cookie with domain
www.erik.io does not match erik.io, the former being more specific.
In RFC 6265, domains are explicitly lower cased when parsing the
Set-Cookie header.
The leading dot in ".local.test.com" is just how chrome views cookies with a "Domain=local.test.com" set (or a "Domain=.local.test.com", which is the same).
Set-Cookie definitions without "Domain=something" views the domain (=host) without a leading dot.
So the leading dot in chrome don't reflect whether or not a leading dot was used from the server, but whether or not that cookie had a "Domain=something" in its definition from the server. (And if it had, the cookie will also be sent to sub-domains).
At least this is what my tests show. Chrome should make this easier to read, for instance view the exact string that defined the cookie and when it was received.
I need to read a cookie created on https://sub1.domain.com from http://origin.domain.com using ColdFusion. I've seen a lot of info about how to create a cookie in a subdomain using CFCOOKIE, but I don't know how to access a cookie that already exists.
Will the HTTPS make this impossible anyway?
ADDENDUM:
The checked answer below correctly addresses the question as worded above. In my case, it did not work. I should have explained: The cookie on sub1.domain.com is created by a hosted third party product - not written in coldfusion and not under my control.
This is really quite easy. When you create the cookie, give it a domain attribute equal to your domain. The important part to remember is that it MUST have a leading dot.
<cfcookie name="mycookie" value="myvalue" domain=".mydomain.com" path="/" />
The leading dot tells the browser to send the cookie to any subdomain of mydomain.com which would include sub.mydomain.com and blah.mydomain.com.
You would then be able to access the cookie from any of the subdomains just as you would any other cookie:
<cfset thevalue = cookie.mycookie />
You should do this as a best practice to support older browsers.
Here is the statement from RFC2109: HTTP State Management Mechanisms that could affect older browsers
"To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if… The value for
the Domain attribute contains no embedded dots or does not start with
a dot."
I believe this is overridden by RFC 2965: HTTP State Management Mechanism which states
"Domain=value OPTIONAL. The value of the Domain attribute specifies
the domain for which the cookie is valid. If an explicitly specified
value does not start with a dot, the user agent supplies a leading
dot."
Which explains why it might be working for you in, presumably, a modern browser. I would still suggest you add it.
I've noticed that many sites create cookies named with a leading underscore. I've also seen similar in defaults for various web frameworks.
What is the significance of the leading underscore in cookie names?
Is it simply a convention, or is there a technical reason?
At the time this question was asked, there wasn't a specific technical reason. However, since about 2015 there has been support in browsers for two specific "cookie prefixes":
__Secure- prefix: Cookies with names starting with __Secure- (dash is part of the prefix) must be set with the secure flag from a secure page (HTTPS).
__Host- prefix: Cookies with names starting with __Host- must be set with the secure flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore, are not sent to subdomains), and the path must be /.
These solve some historical security problems with cookies. By default it is possible for subdomains to set cookies on parent domains, which violates some expectations around the Same-Origin Policy. And it's possible for http:// URLs to set and overwrite cookies that were originally set via an https:// URL. By using these cookie prefixes you can opt out of those problems and into a more secure cookie paradigm.
I'm having an issue with getting a site set up in the web.config file for a Sitecore site. Specifically I can't figure how to use the hostName property to capture the "www" subdomain for a domain (e.g. www.mydomain.com) as well as no specified subdomain (e.g. mydomain.com).
I've experimented a little and found that I can do something like *.mydomain.com and it works. But the problem is that we want users to also be able to go to just mydomain.com and have the site come up. When I have the hostName configured as *.mydomain.com this apparently is not possible.
Any ideas? The Sitecore developer network doesn't say too much on this (unless it's hidden somewhere I couldn't find).
Craig
For a bit more precision than Mark's removing the dot (which will work) you can use pipe separation to list alternative names:
<site hostName="mydomain.com | *.mydomain.com" ... />
That would allow you to configure a second site reallymydomain.com without it being caught by the hostName above. Remember the sites list will be processed in order, so the first match counts even if there's a second match that is more specific.
Try no dot in the hostName:
<site hostName="*mydomain.com" ... />
Both Mark and James answers are correct and will help you resolve multiple domain/subdomain names to a single Sitecore site.
You may instead want to consider setting up a redirect in IIS from the non www domain to the www sub-domain or vice-versa. Having more than one definitive URL for your domain can negatively effect your page rank.
This is a handy module for IIS 7 to help you define redirects. http://www.iis.net/download/urlrewrite
if I have a domain example.com, is there any way to make cookies valid only for that specific domain and not for sub-domains like www.example.com?
I know I can set it to only www.example.com, but can it be without a sub-domain?
Cookies are identified by the combination of their name, domain, and path. So if set correctly, you can limit it's scope to a specific domain/sub-domain and path.
Read Wiki's HTTP Cookie's Attribute Section
or RFC2965
Strictly speaking a cookie carrying the qualifier ";domain=example.com" should not be visible to the "www.domain.com" domain. Whereas ";domain=.example.com" would be visible to the www host.
However I would be very wary of this. I haven't tested this recently but I wouldn't be surprised to see some browsers not conforming properly to this.