Why does putting a dot after the URL remove login information?Why does Chrome remove extension's icon when in 'incognito mode'?How to remove an entry from Chrome's Remembered URLs from the url bar?Why does Firefox use the “chrome://” protocol / schema in URLs?Mac External HDD (time machine) unwanted accessWhy does Chrome incognito keep cookies after the closing browser?Why does Google Search load and then reload when I search from Chrome's URL bar?Why the other URL is opening instead of the expected URL after clicking on a link received from google search in Firefox?Why does this script work as expected in 'curl', but not in the browser?Why does browser always converts $ to %24?Why does my browser not display the index.html file when I type a directory in the URL?
Probably terminated or laid off soon; confront or not?
Write The Shortest Program To Check If A Binary Tree Is Balanced
How does Rust's 128-bit integer `i128` work on a 64-bit system?
How to increase Solr JVM memory
Would the shaking of an earthquake be visible to somebody in a low-flying aircraft?
If someone else uploads my GPL'd code to Github without my permission, is that a copyright violation?
Javascript - Find a deepest node in a binary tree
How to check a file was encrypted (really & correctly)
Can a Hogwarts student refuse the Sorting Hat's decision?
What could prevent players from leaving an island?
What license to choose for my PhD thesis?
Has J.J.Jameson ever found out that Peter Parker is Spider-Man?
Awk to get all my regular users in shadow
Why wasn't interlaced CRT scanning done back and forth?
Why do my fried eggs start browning very fast?
Is it uncompelling to continue the story with lower stakes?
Why should I "believe in" weak solutions to PDEs?
Is Infernal Healing actually worth it as a Wand?
Generate random number in Unity without class ambiguity
How do the surviving Asgardians get to Earth?
Are valid inequalities worth the effort given modern solver preprocessing options?
Repeated! Factorials!
Getting an entry level IT position later in life
What's "halachic" about "Esav hates Ya'akov"?
Why does putting a dot after the URL remove login information?
Why does Chrome remove extension's icon when in 'incognito mode'?How to remove an entry from Chrome's Remembered URLs from the url bar?Why does Firefox use the “chrome://” protocol / schema in URLs?Mac External HDD (time machine) unwanted accessWhy does Chrome incognito keep cookies after the closing browser?Why does Google Search load and then reload when I search from Chrome's URL bar?Why the other URL is opening instead of the expected URL after clicking on a link received from google search in Firefox?Why does this script work as expected in 'curl', but not in the browser?Why does browser always converts $ to %24?Why does my browser not display the index.html file when I type a directory in the URL?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
When I put a dot after the superuser URL, it acted like I wasn't signed in. Why is this happening? What does a dot symbolize in the URL?
google-chrome browser
New contributor
add a comment |
When I put a dot after the superuser URL, it acted like I wasn't signed in. Why is this happening? What does a dot symbolize in the URL?
google-chrome browser
New contributor
2
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (tocom.
) that means cookies no longer resolve tosuperuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.
– Mokubai♦
10 hours ago
1
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago
add a comment |
When I put a dot after the superuser URL, it acted like I wasn't signed in. Why is this happening? What does a dot symbolize in the URL?
google-chrome browser
New contributor
When I put a dot after the superuser URL, it acted like I wasn't signed in. Why is this happening? What does a dot symbolize in the URL?
google-chrome browser
google-chrome browser
New contributor
New contributor
New contributor
asked 10 hours ago
Riley CarneyRiley Carney
1535 bronze badges
1535 bronze badges
New contributor
New contributor
2
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (tocom.
) that means cookies no longer resolve tosuperuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.
– Mokubai♦
10 hours ago
1
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago
add a comment |
2
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (tocom.
) that means cookies no longer resolve tosuperuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.
– Mokubai♦
10 hours ago
1
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago
2
2
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (to
com.
) that means cookies no longer resolve to superuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.– Mokubai♦
10 hours ago
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (to
com.
) that means cookies no longer resolve to superuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.– Mokubai♦
10 hours ago
1
1
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago
add a comment |
2 Answers
2
active
oldest
votes
Adding the dot to the end of the domain name makes it a canonical fully-qualified domain name instead of just a regular fully-qualified domain name, and most browsers treat canonical domain names as being a different domain from the equivalent regular domain name (I'm not sure why they do this though).
A bit of background:
The domain name system is strictly hierarchical, just like a filesystem, or an X.500/LDAP directory. Unlike filesystems ro X.500 though, the hierarchy is listed right-to-left instead of left-to-right. So the rightmost component of a domain name is the top of the hierarchy. Putting a dot to the far right of a domain name makes it canonical, meaning that it's explicitly rooted at the top of the DNS hierarchy. In essence, it's the same as using a full distinguished name instead of a common name in an X.500 lookup, or putting a /
at the beginning of a POSIX path.
Using a canonical FQDN has a few specific implications for how a client system will look up the DNS record for that domain:
- It causes some resolvers to skip any locally defined entries (for example, it will cause some resolvers to ignore
/etc/hosts
on a UNIX-like system). - When used with the
.local
domain, it will force some systems to use mDNS instead of traditional DNS to try and resolve the name. - It causes all resolvers to ignore any configured search domain or local DNS domains when looking up the name.
That last part is the important part, and is the reason that the concept of a canonical FQDN exists. Most systems can be configured with what's called a search domain. When they go to resolve a given domain, they will try looking under any configured search domains first, and only resolve from the top of the hierarchy if they can't find the name in any configured search domains (so, if you had foo.com
configured as a search domain on your system and tried to go to bar.com
in a browser, it would (normally, see below) try to go to bar.com.foo.com
first, and only if it couldn't find that would it try bar.com
directly). Most, but not all, resolvers these days ignore the search domain when resolving a domain that ends with a known top-level domain name (.com
, .net
, etc), so it's not usually necessary for most users to use canonical FQDN's, and thus most people don't know about them.
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
add a comment |
The explanation given by Mokubai is exactly correct, and the problem is in the browser
not identifying that this is the same domain and therefore not sending the cookies.
But the situation is even worse: The dot at the end marks the domain as
fully-qualified (unambiguous), which works quite well with the DNS,
since in the end
all domain names have a dot at the end, even if not specified by the user.
I have even gotten from Fiddler this dialog for superuser.com.
(with dot):
Here are the headers sent with the requests.
https://superuser.com
(sensitive info crossed out)
https://superuser.com.
(with dot no sensitive info needs to be crossed out)
Conclusion: The problem is with the browser not ignoring a dot at the end of
a fully-qualified domain name, as is mandated by the DNS standard.
Further remark: The browser developers were not the only one to fall in this
trap. I have the NoScript add-on installed to stop all JavaScript, butsuperuser.com
(no dot) is allowed through. But NoScript still blockssuperuser.com.
(with dot) as being an unknown website.
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know whatsearch-domain
you have set, I could block access toyoutube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully acceptyoutube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. asyoutube.com
. It is good this behavior happens, even ifyoutube.com
andyoutube.com.
resolve to the same address, etc.
– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "3"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Riley Carney is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1467958%2fwhy-does-putting-a-dot-after-the-url-remove-login-information%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Adding the dot to the end of the domain name makes it a canonical fully-qualified domain name instead of just a regular fully-qualified domain name, and most browsers treat canonical domain names as being a different domain from the equivalent regular domain name (I'm not sure why they do this though).
A bit of background:
The domain name system is strictly hierarchical, just like a filesystem, or an X.500/LDAP directory. Unlike filesystems ro X.500 though, the hierarchy is listed right-to-left instead of left-to-right. So the rightmost component of a domain name is the top of the hierarchy. Putting a dot to the far right of a domain name makes it canonical, meaning that it's explicitly rooted at the top of the DNS hierarchy. In essence, it's the same as using a full distinguished name instead of a common name in an X.500 lookup, or putting a /
at the beginning of a POSIX path.
Using a canonical FQDN has a few specific implications for how a client system will look up the DNS record for that domain:
- It causes some resolvers to skip any locally defined entries (for example, it will cause some resolvers to ignore
/etc/hosts
on a UNIX-like system). - When used with the
.local
domain, it will force some systems to use mDNS instead of traditional DNS to try and resolve the name. - It causes all resolvers to ignore any configured search domain or local DNS domains when looking up the name.
That last part is the important part, and is the reason that the concept of a canonical FQDN exists. Most systems can be configured with what's called a search domain. When they go to resolve a given domain, they will try looking under any configured search domains first, and only resolve from the top of the hierarchy if they can't find the name in any configured search domains (so, if you had foo.com
configured as a search domain on your system and tried to go to bar.com
in a browser, it would (normally, see below) try to go to bar.com.foo.com
first, and only if it couldn't find that would it try bar.com
directly). Most, but not all, resolvers these days ignore the search domain when resolving a domain that ends with a known top-level domain name (.com
, .net
, etc), so it's not usually necessary for most users to use canonical FQDN's, and thus most people don't know about them.
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
add a comment |
Adding the dot to the end of the domain name makes it a canonical fully-qualified domain name instead of just a regular fully-qualified domain name, and most browsers treat canonical domain names as being a different domain from the equivalent regular domain name (I'm not sure why they do this though).
A bit of background:
The domain name system is strictly hierarchical, just like a filesystem, or an X.500/LDAP directory. Unlike filesystems ro X.500 though, the hierarchy is listed right-to-left instead of left-to-right. So the rightmost component of a domain name is the top of the hierarchy. Putting a dot to the far right of a domain name makes it canonical, meaning that it's explicitly rooted at the top of the DNS hierarchy. In essence, it's the same as using a full distinguished name instead of a common name in an X.500 lookup, or putting a /
at the beginning of a POSIX path.
Using a canonical FQDN has a few specific implications for how a client system will look up the DNS record for that domain:
- It causes some resolvers to skip any locally defined entries (for example, it will cause some resolvers to ignore
/etc/hosts
on a UNIX-like system). - When used with the
.local
domain, it will force some systems to use mDNS instead of traditional DNS to try and resolve the name. - It causes all resolvers to ignore any configured search domain or local DNS domains when looking up the name.
That last part is the important part, and is the reason that the concept of a canonical FQDN exists. Most systems can be configured with what's called a search domain. When they go to resolve a given domain, they will try looking under any configured search domains first, and only resolve from the top of the hierarchy if they can't find the name in any configured search domains (so, if you had foo.com
configured as a search domain on your system and tried to go to bar.com
in a browser, it would (normally, see below) try to go to bar.com.foo.com
first, and only if it couldn't find that would it try bar.com
directly). Most, but not all, resolvers these days ignore the search domain when resolving a domain that ends with a known top-level domain name (.com
, .net
, etc), so it's not usually necessary for most users to use canonical FQDN's, and thus most people don't know about them.
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
add a comment |
Adding the dot to the end of the domain name makes it a canonical fully-qualified domain name instead of just a regular fully-qualified domain name, and most browsers treat canonical domain names as being a different domain from the equivalent regular domain name (I'm not sure why they do this though).
A bit of background:
The domain name system is strictly hierarchical, just like a filesystem, or an X.500/LDAP directory. Unlike filesystems ro X.500 though, the hierarchy is listed right-to-left instead of left-to-right. So the rightmost component of a domain name is the top of the hierarchy. Putting a dot to the far right of a domain name makes it canonical, meaning that it's explicitly rooted at the top of the DNS hierarchy. In essence, it's the same as using a full distinguished name instead of a common name in an X.500 lookup, or putting a /
at the beginning of a POSIX path.
Using a canonical FQDN has a few specific implications for how a client system will look up the DNS record for that domain:
- It causes some resolvers to skip any locally defined entries (for example, it will cause some resolvers to ignore
/etc/hosts
on a UNIX-like system). - When used with the
.local
domain, it will force some systems to use mDNS instead of traditional DNS to try and resolve the name. - It causes all resolvers to ignore any configured search domain or local DNS domains when looking up the name.
That last part is the important part, and is the reason that the concept of a canonical FQDN exists. Most systems can be configured with what's called a search domain. When they go to resolve a given domain, they will try looking under any configured search domains first, and only resolve from the top of the hierarchy if they can't find the name in any configured search domains (so, if you had foo.com
configured as a search domain on your system and tried to go to bar.com
in a browser, it would (normally, see below) try to go to bar.com.foo.com
first, and only if it couldn't find that would it try bar.com
directly). Most, but not all, resolvers these days ignore the search domain when resolving a domain that ends with a known top-level domain name (.com
, .net
, etc), so it's not usually necessary for most users to use canonical FQDN's, and thus most people don't know about them.
Adding the dot to the end of the domain name makes it a canonical fully-qualified domain name instead of just a regular fully-qualified domain name, and most browsers treat canonical domain names as being a different domain from the equivalent regular domain name (I'm not sure why they do this though).
A bit of background:
The domain name system is strictly hierarchical, just like a filesystem, or an X.500/LDAP directory. Unlike filesystems ro X.500 though, the hierarchy is listed right-to-left instead of left-to-right. So the rightmost component of a domain name is the top of the hierarchy. Putting a dot to the far right of a domain name makes it canonical, meaning that it's explicitly rooted at the top of the DNS hierarchy. In essence, it's the same as using a full distinguished name instead of a common name in an X.500 lookup, or putting a /
at the beginning of a POSIX path.
Using a canonical FQDN has a few specific implications for how a client system will look up the DNS record for that domain:
- It causes some resolvers to skip any locally defined entries (for example, it will cause some resolvers to ignore
/etc/hosts
on a UNIX-like system). - When used with the
.local
domain, it will force some systems to use mDNS instead of traditional DNS to try and resolve the name. - It causes all resolvers to ignore any configured search domain or local DNS domains when looking up the name.
That last part is the important part, and is the reason that the concept of a canonical FQDN exists. Most systems can be configured with what's called a search domain. When they go to resolve a given domain, they will try looking under any configured search domains first, and only resolve from the top of the hierarchy if they can't find the name in any configured search domains (so, if you had foo.com
configured as a search domain on your system and tried to go to bar.com
in a browser, it would (normally, see below) try to go to bar.com.foo.com
first, and only if it couldn't find that would it try bar.com
directly). Most, but not all, resolvers these days ignore the search domain when resolving a domain that ends with a known top-level domain name (.com
, .net
, etc), so it's not usually necessary for most users to use canonical FQDN's, and thus most people don't know about them.
edited 5 hours ago
answered 9 hours ago
Austin HemmelgarnAustin Hemmelgarn
3,0772 silver badges10 bronze badges
3,0772 silver badges10 bronze badges
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
add a comment |
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
Thank you for your answer. I was really confused why I wasn't logged in to the website and noticed a dot was on the end of URL. After trying both of the urls with or without dot I thought the behavior was interesting :P Your explanation was clear and concise and gave me a relative understanding of why the browser reacted the way it did.
– Riley Carney
7 hours ago
add a comment |
The explanation given by Mokubai is exactly correct, and the problem is in the browser
not identifying that this is the same domain and therefore not sending the cookies.
But the situation is even worse: The dot at the end marks the domain as
fully-qualified (unambiguous), which works quite well with the DNS,
since in the end
all domain names have a dot at the end, even if not specified by the user.
I have even gotten from Fiddler this dialog for superuser.com.
(with dot):
Here are the headers sent with the requests.
https://superuser.com
(sensitive info crossed out)
https://superuser.com.
(with dot no sensitive info needs to be crossed out)
Conclusion: The problem is with the browser not ignoring a dot at the end of
a fully-qualified domain name, as is mandated by the DNS standard.
Further remark: The browser developers were not the only one to fall in this
trap. I have the NoScript add-on installed to stop all JavaScript, butsuperuser.com
(no dot) is allowed through. But NoScript still blockssuperuser.com.
(with dot) as being an unknown website.
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know whatsearch-domain
you have set, I could block access toyoutube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully acceptyoutube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. asyoutube.com
. It is good this behavior happens, even ifyoutube.com
andyoutube.com.
resolve to the same address, etc.
– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
add a comment |
The explanation given by Mokubai is exactly correct, and the problem is in the browser
not identifying that this is the same domain and therefore not sending the cookies.
But the situation is even worse: The dot at the end marks the domain as
fully-qualified (unambiguous), which works quite well with the DNS,
since in the end
all domain names have a dot at the end, even if not specified by the user.
I have even gotten from Fiddler this dialog for superuser.com.
(with dot):
Here are the headers sent with the requests.
https://superuser.com
(sensitive info crossed out)
https://superuser.com.
(with dot no sensitive info needs to be crossed out)
Conclusion: The problem is with the browser not ignoring a dot at the end of
a fully-qualified domain name, as is mandated by the DNS standard.
Further remark: The browser developers were not the only one to fall in this
trap. I have the NoScript add-on installed to stop all JavaScript, butsuperuser.com
(no dot) is allowed through. But NoScript still blockssuperuser.com.
(with dot) as being an unknown website.
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know whatsearch-domain
you have set, I could block access toyoutube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully acceptyoutube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. asyoutube.com
. It is good this behavior happens, even ifyoutube.com
andyoutube.com.
resolve to the same address, etc.
– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
add a comment |
The explanation given by Mokubai is exactly correct, and the problem is in the browser
not identifying that this is the same domain and therefore not sending the cookies.
But the situation is even worse: The dot at the end marks the domain as
fully-qualified (unambiguous), which works quite well with the DNS,
since in the end
all domain names have a dot at the end, even if not specified by the user.
I have even gotten from Fiddler this dialog for superuser.com.
(with dot):
Here are the headers sent with the requests.
https://superuser.com
(sensitive info crossed out)
https://superuser.com.
(with dot no sensitive info needs to be crossed out)
Conclusion: The problem is with the browser not ignoring a dot at the end of
a fully-qualified domain name, as is mandated by the DNS standard.
Further remark: The browser developers were not the only one to fall in this
trap. I have the NoScript add-on installed to stop all JavaScript, butsuperuser.com
(no dot) is allowed through. But NoScript still blockssuperuser.com.
(with dot) as being an unknown website.
The explanation given by Mokubai is exactly correct, and the problem is in the browser
not identifying that this is the same domain and therefore not sending the cookies.
But the situation is even worse: The dot at the end marks the domain as
fully-qualified (unambiguous), which works quite well with the DNS,
since in the end
all domain names have a dot at the end, even if not specified by the user.
I have even gotten from Fiddler this dialog for superuser.com.
(with dot):
Here are the headers sent with the requests.
https://superuser.com
(sensitive info crossed out)
https://superuser.com.
(with dot no sensitive info needs to be crossed out)
Conclusion: The problem is with the browser not ignoring a dot at the end of
a fully-qualified domain name, as is mandated by the DNS standard.
Further remark: The browser developers were not the only one to fall in this
trap. I have the NoScript add-on installed to stop all JavaScript, butsuperuser.com
(no dot) is allowed through. But NoScript still blockssuperuser.com.
(with dot) as being an unknown website.
edited 8 hours ago
answered 9 hours ago
harrymcharrymc
278k14 gold badges293 silver badges606 bronze badges
278k14 gold badges293 silver badges606 bronze badges
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know whatsearch-domain
you have set, I could block access toyoutube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully acceptyoutube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. asyoutube.com
. It is good this behavior happens, even ifyoutube.com
andyoutube.com.
resolve to the same address, etc.
– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
add a comment |
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know whatsearch-domain
you have set, I could block access toyoutube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully acceptyoutube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. asyoutube.com
. It is good this behavior happens, even ifyoutube.com
andyoutube.com.
resolve to the same address, etc.
– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know what
search-domain
you have set, I could block access to youtube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully accept youtube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. as youtube.com
. It is good this behavior happens, even if youtube.com
and youtube.com.
resolve to the same address, etc.– ivanivan
9 hours ago
Good reasoning, etc. but your conclusion is off. If I can hijack your DNS, and know what
search-domain
you have set, I could block access to youtube.com.
(notice trailing . to make it fully qualified) and your browser would cheerfully accept youtube.com.your.search-domain.tld
but it would appear in your browser URL field, etc. as youtube.com
. It is good this behavior happens, even if youtube.com
and youtube.com.
resolve to the same address, etc.– ivanivan
9 hours ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
"The problem is with the browser not ignoring a dot at the end of a fully-qualified domain name, as is mandated by the DNS standard." There is no such requirement. It is allowed in URIs as per RFC3986 and should be used "if it is necessary to distinguish between the complete domain name and some local domain".
– Bob
1 hour ago
add a comment |
Riley Carney is a new contributor. Be nice, and check out our Code of Conduct.
Riley Carney is a new contributor. Be nice, and check out our Code of Conduct.
Riley Carney is a new contributor. Be nice, and check out our Code of Conduct.
Riley Carney is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1467958%2fwhy-does-putting-a-dot-after-the-url-remove-login-information%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Curious. Same behaviour on Firefox so it's not just some weird behaviour of Chrome. I suspect the extra dot is changing the domain (to
com.
) that means cookies no longer resolve tosuperuser.com
as a domain, and as a result you are not logged in because you don't have any session cookies. It would be good for someone with more definite knowledge to answer.– Mokubai♦
10 hours ago
1
If you click the button to login you get redirected to superuser.com and as a result logged in. Note: this is not just a Super User issue, you get the same result if you add a dot to youtube.com.
– Mokubai♦
9 hours ago