We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
5-
3
-
2
- +2
12 Comments
a session is deleted when the browser is terminated,
a cookie is written on your computer and is still active the next time you visit the website
examples session and cookies:
session("name")=request.fo
and later call it by: <%=session("name")%> or
if session("name")="Tom Hanks" then ...
response.cookies("website"
response.cookies("website"
and later call it by:
<input NAME="name" value="<%=request.cookies(
a cookie is written on your computer and is still active the next time you visit the website
examples session and cookies:
session("name")=request.fo
and later call it by: <%=session("name")%> or
if session("name")="Tom Hanks" then ...
response.cookies("website"
response.cookies("website"
and later call it by:
<input NAME="name" value="<%=request.cookies(
what was that?
the difference betweeen a cookie(response.cookies) and a session cookie(session("")) is where the cookie is stored(client/server)
your Q was "what is the difference between ASP cookie?..and what?
plz make this more clear
the difference betweeen a cookie(response.cookies) and a session cookie(session("")) is where the cookie is stored(client/server)
your Q was "what is the difference between ASP cookie?..and what?
plz make this more clear
A Session cookie is a normal cookie with the name "ASPSESSIONID". A normal cookie don't having an expiration date.
Cookies without an expiration date expire when the browser closes. Session cookies, in opposite to other cookies, may also time out (at Session.SessionTimeout) - but that's not happening client-side, but server-side. That means IIS stops having this information stored and thus, a new Session cookie will be set when there's activity again.
So, Session cookies are client-side the same as normal cookies not having an expiration date.
You can set the expiration date with a normal cookie:
Response.Cookies("myCookie
Response.Cookies("myCookie
and delete it by:
Response.Cookies("myCookie
We call that "persistant" cookies.
If the user's browser settings don't allow cookies, Session cookies won't work, too, and a new Session cookie will be set with loading another page.
IE5 differs and lets the user choose if to allow persistant or non-persistant cookies.
As for dis-/advantages:
+ If that isn't disabled server-side, a unique SessionID will be set with a Session cookie. You can also generate one, manually, (and identify the user by that) but the IIS Session engine only recognizes its own cookies. If it's able to do so, values you store in your custom Session cookies,
Session("x") = "y"
nextpage.asp:
x = Session("x")
can be retrieved. That's just easy and comfortable.
+ If you need to store values with the user for a longer time than this browser session, you would manually set cookies with an expiration date.
Cookies without an expiration date expire when the browser closes. Session cookies, in opposite to other cookies, may also time out (at Session.SessionTimeout) - but that's not happening client-side, but server-side. That means IIS stops having this information stored and thus, a new Session cookie will be set when there's activity again.
So, Session cookies are client-side the same as normal cookies not having an expiration date.
You can set the expiration date with a normal cookie:
Response.Cookies("myCookie
Response.Cookies("myCookie
and delete it by:
Response.Cookies("myCookie
We call that "persistant" cookies.
If the user's browser settings don't allow cookies, Session cookies won't work, too, and a new Session cookie will be set with loading another page.
IE5 differs and lets the user choose if to allow persistant or non-persistant cookies.
As for dis-/advantages:
+ If that isn't disabled server-side, a unique SessionID will be set with a Session cookie. You can also generate one, manually, (and identify the user by that) but the IIS Session engine only recognizes its own cookies. If it's able to do so, values you store in your custom Session cookies,
Session("x") = "y"
nextpage.asp:
x = Session("x")
can be retrieved. That's just easy and comfortable.
+ If you need to store values with the user for a longer time than this browser session, you would manually set cookies with an expiration date.
By,
> A normal cookie don't having an expiration
date.
(first line), I meant,
> A Session cookie is a normal cookie don't having an expiration date.
But it's the "one" cookie IIS' Session engine looks at when identifying the user.
> A normal cookie don't having an expiration
date.
(first line), I meant,
> A Session cookie is a normal cookie don't having an expiration date.
But it's the "one" cookie IIS' Session engine looks at when identifying the user.
robber,
Sound like to me, the session is created by ASP itself.
What if I want to use straight cookies, and not session
at all ?
Sound like to me, the session is created by ASP itself.
What if I want to use straight cookies, and not session
at all ?
Session cookies will be set, though. That doesn't harm for most users but anyway, you can state at the top of your scripts,
<%@ ENABLESESSIONSSTATE=True|F
or set that in IIS, in the web application properties.
<%@ ENABLESESSIONSSTATE=True|F
or set that in IIS, in the web application properties.
You need to check for cookies. There's a pitfall, so follow.
Set a test cookie:
Response.Cookies("test") = "test"
Then, (at the top of your script) check if the cookie has been accepted:
If Len(Request.Cookies("test"
Response.Redirect "wouldyoupleaseacceptcooki
End If
The pitfall (or bait) is that even if the user doesn't have cookies enabled - if you set a cookie and check it on the same page - it always appears to be set.
Thus, one strategy is to set a testcookie at all entry pages and to check the cookie on all follow-up pages.
Obviously, it's hard to pre-determine where the user comes in and where he navigates, next.
What I'm usually doing is, setting the testcookie by server-side ASP, and checking it by client-side JavaScript:
<%
Response.Cookies("testcook
%>
<HTML>
<HEAD>
</HEAD>
<BODY>
<script language=javascript>
if (document.cookie.indexOf("
document.location.href = "cookies.asp"
</script>
... regular HTML code ...
</BODY>
</HTML>
And, you apparently want to know it quite in-depth - you'ld also need to ensure that the user has JavaScript enabled:
<%
Response.Cookies("testcook
%>
<HTML>
<HEAD>
</HEAD>
<BODY>
<script language=javascript>
if (document.cookie.indexOf("
document.location.href = "cookies.asp"
</script>
<noscript language=javascript>
Please activate JavaScript.
</script>
... regular HTML code ...
</BODY>
</HTML>
There is a third option (beneath server-side setting and checking cookies on different pages, and doing that server- and client-side on the same page) - checking for cookies by using the www.browserhawk.com component in the global.asa, and from there, deciding what to do (it's great but not common).
These are the only options.
Set a test cookie:
Response.Cookies("test") = "test"
Then, (at the top of your script) check if the cookie has been accepted:
If Len(Request.Cookies("test"
Response.Redirect "wouldyoupleaseacceptcooki
End If
The pitfall (or bait) is that even if the user doesn't have cookies enabled - if you set a cookie and check it on the same page - it always appears to be set.
Thus, one strategy is to set a testcookie at all entry pages and to check the cookie on all follow-up pages.
Obviously, it's hard to pre-determine where the user comes in and where he navigates, next.
What I'm usually doing is, setting the testcookie by server-side ASP, and checking it by client-side JavaScript:
<%
Response.Cookies("testcook
%>
<HTML>
<HEAD>
</HEAD>
<BODY>
<script language=javascript>
if (document.cookie.indexOf("
document.location.href = "cookies.asp"
</script>
... regular HTML code ...
</BODY>
</HTML>
And, you apparently want to know it quite in-depth - you'ld also need to ensure that the user has JavaScript enabled:
<%
Response.Cookies("testcook
%>
<HTML>
<HEAD>
</HEAD>
<BODY>
<script language=javascript>
if (document.cookie.indexOf("
document.location.href = "cookies.asp"
</script>
<noscript language=javascript>
Please activate JavaScript.
</script>
... regular HTML code ...
</BODY>
</HTML>
There is a third option (beneath server-side setting and checking cookies on different pages, and doing that server- and client-side on the same page) - checking for cookies by using the www.browserhawk.com component in the global.asa, and from there, deciding what to do (it's great but not common).
These are the only options.
need a cookies.asp?! :)
http://rechten.kub.nl/projecten/cookiecheck.asp
(sorry, some text in dutch, but it says something about what cookies are and how you can accept cookies)
moswa
http://rechten.kub.nl/projecten/cookiecheck.asp
(sorry, some text in dutch, but it says something about what cookies are and how you can accept cookies)
moswa
Featured Post
Make Your Microsoft Dynamics Investment Count & Drastically Decrease Training Time by Providing Intuitive Step-By-Step WalkThru Tutorials.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I have helped a lot of people on EE with their coding sources and have enjoyed near about every minute of it. Sometimes it can get a little tedious but it is always a challenge and the one thing that I always say is:
Â
The Exchange of informatio…
I was asked about the differences between classic ASP and ASP.NET, so let me put them down here, for reference:
Let's make the introductions...
Classic ASP was launched by Microsoft in 1998 and dynamically generate web pages upon user interact…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
If you’ve ever visited a web page and noticed a cool font that you really liked the look of, but couldn’t figure out which font it was so that you could use it for your own work, then this video is for you!
In this Micro Tutorial, you'll learn yo…
- Microsoft Applications
- Windows 10
- Windows OS
- Fonts Typography
- Windows 7, Microsoft Word
Suggested Courses
Course of the Month8 days, 19 hours left to enroll
734 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.