Forum Moderators: open
I have a rather large site, and many of the pages are in ASP. On the Google News forum, someone mentioned a problem with SE's and session id's. I only use SID's on a few "private" pages, and those are blocked by the robots.txt files and meta tags anyway.
However, if I set my browser to ask for each cookie, when I go to an ASP page on my site that I don't have SID's on, the browser still asks if I want to accept the cookie. And, if I do, I then find it when I search the cookies folder in the browser.
So here's the simple question (I hope it's simple): does any page with an .asp file extension automatically generate a cookie?
I'm a bit confused, so thanks for any clarification.
The ASP needs to maintain some type of relationship with the user across pages.
The Session ID is created by the server each time a new browser pings that page, and that ID is recorded in a cookie on the user's machine.
The id corresponds to lots of information about the Session on the server, which is better than placing lots of cookies on the user's machine.
So, the end user does indeed have to have cookies enabled to maintain state from page to page, without having to login to everypage, or to pass that long ID number on every page.
There are ways to pass the id number without putting it in the URL. You can make a hidden form element out of it and pass it in every POST if you want to, but a cookie is the easiest way.
My concern was that SE's wouldn't be able to read the pages. Looking at my log files, I don't see that the SID's are a factor. All the SE's are crawling the site just fine.
Now if Google would just index the %@#(%@ site, I'd be a happy guy. ;)
ASP.NET by default uses cookies to keep track of the session id.
A cookie merely contains a bunch of variables that get sent along with every single HTTP request to a particular domain. I presume that search engines simply ignore the cookies (which you can set your own web browser to do by turning off cookies).
(ie: mypage.aspx?id=1 was a different page than mypage.aspx?id=2) and Google didn't index anything.
This always bothered me about webmasters.
By using a query string, you are creating dynamic pages. Pages that wouldn't exist outside of the ASPX. We do this to save coding and hard drive space. One generic web page can show thousands of items, etc.
Of course Google can't index them because they don't exist outside of a request by the user. That's why it's the Request object we use.
Google should find mypage.aspx without a problem though, because that page actually exists.
If you want google to find all those dynamic pages, you will need to have them exist before someone clicks on them.
If a user clicks from asp to html... will they generate a new session id if the click back to an asp page?
When the session is created the user is handed a cookie, for the duration of their visit their browser will always present that cookie with every request, and as long as this happens they wont be assigned a new session id.
Whether they are viewing plain HTML or ASP isn't an issue - once their browser is given the cookie it will retain it.
Can a user session track across multiple domains or is a new id issued?
The nature of session cookies means they should be tied to the domain that issued them for security reasons - also the data associated with that session id would be linked to the IIS instance (website) that issued them.
Otherwise people using shared hosting would find that going between two sites on the same server would cause all of their session data to carry across (a bad thing).
- Tony
Once you know that Google doesn't like querystings, with ASP.NET there are many ways to accomplish the exact same effect without using them.
5stars: the session cookie stays in your computer's memory as long as your browser window is open. Every request you send to that domain has the cookie attached. It just gets ingored when there's a request for a non-ASPX page.
The network was all iMacs 9.2. Everyone logged in with a guest account.
When people launched my site, a session cookie was indeed written, but soon people were logging into each other's accounts! They'd refresh the page and see someone else's screens! It was driving me bananas, and my customers were getting nervous....
It turned out that whoever set up the network, decided that all cookies for the guest account wouldn't reside o the local hard drive! He had them all redirect to one folder on a central HD somewhere. So, everytime someone logged on, it would rewrite the cookie!
ACK!