Match ASP.NET Profile ID with page request

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

I have an understanding of all of what you mention, but am not sure how Profile State management works when it comes to identifying each page request. The focus is on each page request with respect to Profile state management and how they do it.

Most articles I've come across seem to imply that Profile Properties somehow magically know which browser has made the request, so they tend to skip the explanation of how this actually happens.

Each web page is independent, so the only way Profile Properties know which browser sent any page is by using a mechanism like cookies, url embedding, or some form of browser caching or similar.

Simply put, how does the Profile state management system know which page request belongs to its unique ID?

With Session State they use cookies and url embedding, what is used with Profile State?

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

So does Profile State management depend on Session State, or are you referring to different things when you mention "session" and "Session State".

Is it correct to say that a session's data is server-side only? If so, how does it communicate with a browser so it can connect the correct session data with the correct browser?

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

When a client makes its initial request to the server, the server generates a Session ID and passes that back to the client. The client sends the Session ID with every subsequent request so the server knows which session/client is making the request.

Many articles call this an in-memory cookie that is deleted when the browser closes, so I think I was referring to this when I mentioned cookie. I probably should have called it in-memory cookies, however, as far as I know, url embedding is used in cookieless sessions, but again, perhaps my terminology is incorrect.

Yes, for the purpose of this discussion.

This tells me that you don't really believe that Sessions are always used with Profile State, or am I getting it wrong?

"This tells me that you don't really believe that Sessions are always used with Profile State, or am I getting it wrong?"
Profile information is loaded into a Session when requested so the Profile information can follow the client's requests - which is what you seem to be asking about. Technically, Profile information can exist without a Session (just by being in a database - but the information is not useful there). I'm not trying to be coy, just precise.

Sessions do not equal cookies, regardless of what you may have read. Here's some information on Sessions and IIS:
http://msdn.microsoft.com/en-us/library/ms178586(v=vs.80).aspx

ASKER

Yes, I can see now that technically Profile data don't need Sessions, and Sessions don't always need cookies, but it is the web request / response process and the stateless nature of the web that requires a means of always knowing the logged on status of a specific web page request across web requests.

So, just to clarify your comment,

the server generates a Session ID and passes that back to the client

, where in the client is the Session ID stored?

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

Thanks, this has been helpful and informative.

Happy to help.