When I was doing some web design, I found one interesting thing.
When I type
http://example.com/xxx/xxx
it always asks me for credentials. However, when I use
http://www.example.com/xxx/xxx
it logs me in directly! I know there is something with the cookie.
But what I really want to know is:
What is the difference between http://example.com and http://www.example.com?
Do tell me it is the browser automatically adding "www" to the url.
Thanks,
: )
www is a subdomain like any other (e.g. http://math.stackexchange.com/). It's just a convention to have it point to the same place as the main domain. This answer has some good points about why you would use www.
Related
I have a Wordpress website and want to have in form of https://website.com. When I test it on GTmertix in form of http://www.website.com, I receive multiple landing page redirects like this:
Avoid landing page redirects for the following chain of redirected URLs.
http://www.website.com/
http://website.com/
https://website.com/
I have set the base domain on https://website.com format in Wordpress, and also I have done many things on .htaccess file to redirect http to https, but could not solve this issue.
May you help me please?
Without the domain, it is difficult to diagnose (and even then it may be difficult without seeing your .htaccess). Something is obviously redirecting http://www.example.com to http://example.com rather than directly to HTTPS.
You could try looking further up the chain, such as at your domain registrar/DNS provider. If you are behind a proxy like Cloudflare, I'd also be curious if this happens when you add the instance's IP address in your hosts file and try connecting directly - that would at least determine if the issue exists on the host itself or further up the chain.
I'm not sure so please explaine me if you know. I have problem with domain in Cookies.
According to the newewst rfc 6265 document it doesn't matter if domain in cookie starting with 'dot' or not.
For example:
Set-Cookie: example.com means the same as .example.com and it's valid for all subdomains like something.example.com and of course example.com .
So I have a question. How about "www"... If client have cookie setting to www.example.com -> client shouldn't send cookie for "example.com"??? But should send to: www.example.com???
Or maybe "www." is ignored too?
Could you explain me that? I can't find the answer.
Thank you.
No, there's nothing special about www; it works the same as any other subdomain. www.example.com is different to example.com as far as cookies are concerned. Regardless of your opinion, that is the fact. www as a subdomain is not special.
This is an important point, and does catch a lot of beginners out, particularly when they write links in their sites with the full domain name. If you navigate from www.example.com/index.html to example.com/nextpage.html, your cookies may not be visible on the second page if the cookies were created on the index page in the www subdomain.
You say you've already read the RFC, but you might find that this answer gives a little more clarification on it.
Hope that helps.
I have my production site's app pool to recycle every 2 hours or so. I noticed that when the first call to the site is made, the App Pool caches the base url (e.g. www.mysite.com). This makes sense as this is used to resolve relative paths in ASP.NET e.g. ~/MyFolder/MyPage.aspx, which is resolved to:
http://www.mysite.com/MyFolder/MyPage.aspx
However since the site can be reached via our host name e.g.
http://masdfg.my.provider.net
IIS thinks the url is
http://masdfg.my.provider.net/MyFolder/MyPage.aspx
As you can image, this causing an issue with SSL as well as others. How can I prevent this from happening?
UPDATE: The work around was to create a url redirect. If anyone knows how to prevent this let me know.
I hope I've understood your question correctly, but please do let me know if I haven't.
It sounds like the sole issue you have is that when you write the links to the response they sometimes reference the wrong root URL.
I notice that you use ~/ . This would resolve and write the entire URL to the response I think. It is better to use only / when writing links to the response.
So in your example you would write /myfolder/mypage.aspx. The browser would then resolve the / to mean that it's from the root address of the site, whichever that may be.
Like I said, I hope I've understood your question correctly and apologies if I haven't.
I know it's a long shot, but I've had a similar problem with my IIS setup. I solved it by going to the already mentioned "bindings" window through "Edit Bindings".
Then I removed all the not wanted bindings, then adding the hostname www.mydomain.com the server should answer to.
Finally I edited the windows hosts file at
%windir%\System32\drivers\etc\hosts
Adding the line
127.0.0.1 www.mydomain.com
This ensures that www.mydomain.com always resolves to the local computer.
After executing iisreset.exe as administrator my problem was over.
HttpContext.Current.Request.Url is not a cacheable item. That value comes from the HOST value of the HTTP headers. Which means it is passed in to the application from the request.
The only time it should take that second URL is if the requests HOST value was masdfg.my.provider.net
There are three possible fixes here. The first is to set your bindings and have any requests to masdfg.my.provider.net be forwarded over to www.mysite.com
The second, because your primary issue appears to be about SSL is to get a unified communications (UC) SSL certificate and install that on your server. This would be to cover the mysite.com and masdfg.my.provider.net domain names.
The third is to simply create a separate IIS site which points to the exact same production directory as the first one. Each site would have only 1 domain name it's responsible for.
We've recently run into an issue with our ASP.NET application where if a user goes to ourcompany.com instead of www.ourcompany.com, they will sometimes end up on a page that does not load data from the database. The issue seems to be related to our SSL certificate, but I've been tasked to investigate a way on the code side to fix this.
Here's the specific use case:
There is a user registration page that new users get sent to after they "quick register" (enter name, email, phone). With "www" in the URL (e.g. "www.ourcompany.com") it works fine, they can proceed as normal. However, if they browsed to just "ourcompany.com" or had that bookmarked, when they go to that page some data is not loaded (specifically a list of states from the DB) and, worse, if they try to submit the page they are kicked out entirely and sent back to the home page.
I will go in more detail if necessary but my question is simply if there is an application setting I can say to keep the session for the app regardless of if the URL has the "www" or not? Buying a second SSL cert isn't an option at this point unless there is no recourse, and I have to look at a way to solve this without another SSL.
Any ideas to point me in the right direction?
When your users go to www.ourcompany.com they get a session cookie for the www subdomain. By default, cookies are not shared across subdomains, which is why users going to ourcompany.com do not have access to their sessions.
There is a useful thread discussing this issue here. The suggested solution is:
By the way, I implemented a fairly good fix/hack today. Put this code
on every page: Response.Cookies["ASP.NET_SessionId"].Value =
Session.SessionID; Response.Cookies["ASP.NET_SessionId"].Domain =
".mydomain.com";
Those two lines of code rewrite the Session cookie so it's now
accessible across sub-domains.
Doug, 23 Aug 2005
Surely you are trying to solve the wrong problem?
Is it possible for you to just implement URL rewriting and make it consistent?
So for example, http://example.com redirects to http://www.example.com ?
For an example of managing rewriting see:
http://paulstack.co.uk/blog/post/iis-rewrite-tool-the-pain-of-a-simple-rule-change.aspx
From the browsers point of view, www.mysite.com is a different site than mysite.com.
If you have a rewrite engine, add a rule to send all requests to www that don't already have it.
Or (this is what I did) add a separate IIS site with the "mysite.com" host header and set the IIS flag to redirect all traffic to www.
In either of these cases, any time a browser requests a page without the www prefix, it will receive a redirect response sending it to the correct page.
Here's the redirect site home directory properties:
And the relevant host header setting:
This fixes the issue without requiring code changes, and incidentally prevents duplicate search results from Google etc.
Just an update, I was able to fix the problem with a web.config entry:
<httpCookies domain=".mycompany.com" />
After adding that, the problem went away.
If I have 2 domain names that point to same website (for example: microsoft.com and microsoft.net both point to microsoft.com), how can search engines distinguish that these two websites are the same website and not duplicate content?
My question is because I know that Google, for example, have a duplicate content filter, and I want know what to do to declaratively say that the two domains are the same and are not duplicate content websites.
Thanks!
Choose which is to be the primary domain and then implement a 301 redirect on the other.
Is it important that the user always stays at the domain entered, or are the second merely an alias for the first? If the latter is the case, you could do a HTTP redirect to the desired domainname, when the user visits one of the aliases.
EDIT: Guess Mat beat me to it. :-)
like guys says use 301 header to redirect. but also try to put a robot.txt to deny bots access and avoid have duplicate content
make one site a 301 redirect to the other
but do-not attempt the idiotic idea of a robots.txt
{as for 1 if the secondary site is a 301 to the "real" site a robots.txt couldn't exist as all requests for any content are directed at the primary, that means everything including a robots.txt
thus no duplicate content anywhere all content on one site only
the other just says {your in the wrong place go here instead}
You can establish a permanant forward (301) with most domain hoster.
For subdomains, you can normally have an HttpHandlers that take care of that.