<sessionState cookieless="true" />

[Water Cooler v2]

What do you mean by a cookieless session state? When you set the
sessionState section's cookieless attribute to true in the web.config
file, what does that mean?

I read this
(http://msdn.microsoft.com/library/d...us/cpgenref/html/gngrfSessionstateSection.asp)
and it does not explain the meaning of cookieless.

 

[Juan T. Llibre]

It means that ASP.NET doesn't use cookies to maintain session state.

Instead, ASP.NET will maintain session state by inserting a random ID,
like : http://yourserver.com/(S(n1rpjs55doute2vjvs0rd155))/helloworld.aspx
in your URL.

Then, *that* ID identifies the state of your client's session,
instead of cookies being used to maintain session state.

 

[Water Cooler v2]

aha! thanks! so, then it doesn't have anything to do with the fact that
I want to drop cookies on the client for other stuff such as UserID on
my own? I mean, other than the fact that the client browser user
cookies or not, it doesn't have anything to do with placing a
restriction on the developer to use cookies himself for storing
information on the client?

 

[Water Cooler v2]

Also, is there a way we could check if a client has cookies
enabled/turned on or not?

 

[Juan T. Llibre]

Water Cooler v2,

"cookieless" means just that : no cookies at all!

With cookieless="true", you can still use a different method
to assign a way to follow a client's session, like a UserID,
as you mention, but you don't get to use cookies at all.

 

[Juan T. Llibre]

If you set cookieless = "false", what you
can do is issue a cookie, and try to retrieve it.

If you can retrieve it, the client has cookies enabled;
if you can't retrieve it, the client doesn't have cookies enabled.

 

[Water Cooler v2]

I am still confused. My question is,

With cookieless, are we telling the server

(1) Hey, look! I might use cookies if I like and if the client has them
enabled, but you, you don't get to use cookies to persist session
information;

or, are we telling the server

(2) The client is a moron. He's got his cookies turned off. Neither do
you, nor do I get any cookies. So, don't drop a cookie for persisting
session info, and I won't drop any cookies, too, because the "client
won't let me". Instead of baking session id into a cookie, just pass it
along the URL and I'll understand?

 

[Juan T. Llibre]

re:

I am still confused. My question is,
With cookieless, are we telling the server

(1) Hey, look! I might use cookies if I like and if the client has them
enabled, but you, you don't get to use cookies to persist session
information;

With "cookieless" your server doesn't get to use cookies at all,
as the name of the setting implies.

re:

(2) The client is a moron. He's got his cookies turned off.

Setting cookieless ="true" means that you don't get to *send*
a cookie, regardless of whether the client has them enabled or not.

"cookieless" is a server setting, not a client setting.

 

[Water Cooler v2]

Setting cookieless ="true" means that you don't get to *send*
a cookie, regardless of whether the client has them enabled or not.

That line explains it. Or, may be I just got my eureka from the
emphasis on *send*, as you typed it. So, it is the second case I
thought? The client is a moron one.

Thanks!

 

[Water Cooler v2]

Oooops! Please ignore the previous message. I've been awake too long.
What I meant was that I got the eureka with the *send* in your message
and the eureka I got was that it was the first option I was thinking
of: "we tell the server that you don't get to use/send a cookie to the
client to persist session info. We don't know whether the client has
turned cookies on or off."

 

[Stefan]

Request.Browser.Cookies will tell you if client has cookies enabled.

The cookieless setting simply determines how the asp.net application
saves the session ID
to overcome the statelessness of http. If it is set to "true", the
session ID is saved as cookie.
If set to "false", it will use URL rewriting to save the sessID. Also,
you can still issue other cookies
to the client as Juan has pointed out (such as a user name or zip).
However, before saving state
in a cookie you should definitely check if the browser has cookies
enabled (see above), or choose
another state storage mechanism.

 

[Water Cooler v2]

Thanks, Juan for the answer and Stefan for amplifying it.

 

[Juan T. Llibre]

Unless I'm mistaken, Request.Browser.Cookies will tell you
if the browser is *capable* of accepting cookies, and not
whether the cookies are *enabled*.

 

[Stefan]

Juan, you are right, my bad.

There is not really an easy way out. You could check if the ".ASPXAUTH"
cookie exists to check if cookies are enabled. This presupposes though
that
- your app has set cookieless to "false"
- the client has not cookies disabled altogehter
- hasn't disabled cookies after the aspxauth cookie was set

The only safe way to check seems to do some probing by sending a cookie
in the http response (maybe along with a meta refresh to make it more
seamless) and then check in the next request if the cookie comes back.

Sorry for the misinformation
-Stefan