This message was discovered on ASPFriends.com 'aspnghttphandlers' list.
| Julian Voelcker |
I want to be able to develop a function that tests to see if a visitor
to a website has cookies enabled or not and then get it to change the
cookieless attribute of the sessionState dynamically to what's
appropriate for the user.
I am using Forms Authentication for part of the site and it has to work
for all users. I know I could just set cookieless to true, however
this results in messy URLs and it is also a security risk when people
bookmark the site.
Someone has suggested that I should use an IHttpModule, but I don't
know whether this is right or where to start.
I would appreciate as much help as possible with this!
(PS - I'm surprised someone hasn't asked for this before)
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
|
|
| |
| |
| ToddC@match.com |
You do not want to change your web.config on the fly. For one thing it
forces a recompile your web application.
Your best bet is to roll your own, and an HTTPModule is one way to do this.
Sessions work by passing around a key, either by Cookie, URL, Hidden Form
field, ViewState etc. Take your pick. They then look up the "State"
information for the user and populate an object, list, array, variable
whatever.
Believe it or not most people accept Session cookies, so much so that major
sites have stopped allowing users on their site if they turn them off.
What you are trying to do is much more complicated (fun too) than writing a
function.
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 22, 2002 10:00 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Changing Session state per user
I want to be able to develop a function that tests to see if a visitor
to a website has cookies enabled or not and then get it to change the
cookieless attribute of the sessionState dynamically to what's
appropriate for the user.
I am using Forms Authentication for part of the site and it has to work
for all users. I know I could just set cookieless to true, however
this results in messy URLs and it is also a security risk when people
bookmark the site.
Someone has suggested that I should use an IHttpModule, but I don't
know whether this is right or where to start.
I would appreciate as much help as possible with this!
(PS - I'm surprised someone hasn't asked for this before)
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Stephen Beeman |
[Original message clipped]
Hi Julian,
Here's how to do this with an HttpModule. It's a big hammer for a small
nail, but if (like me) you absolutely must support cookieless users it's the
best way I've found.
First, create a stub HttpModule to handle the BeginRequest event. There's an
excellent HOWTO on this from Microsoft at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q307996. Note that
you need to hook BeginRequest, rather than the seemingly more appropriate
AcquireRequestState, because you have to make sure you hook an event that
occurs before AuthenticateRequest.
Your BeginRequest handler is going to be pretty complicated, because it's
doing a bunch of tasks: It determines whether the user's browser accepts
cookies (no mean feat in itself); if the user is cookieless, it extracts
session information from the URL; if the user is cookied, it gets the
information from a cookie; and finally, wherever the information came from,
it gets stored in the Context.Items collection.
Now, I don't have working code I can give you, since my version of this does
substantially more and is pretty involved. Here's what the guts of your
module will more or less look like, though--no guarantees this will compile
on the first try. ;-)
private string GetMunge(ref string path)
{
Regex matcher = new Regex(@"^(?:[\/])?\(([0-9A-F]{32,32})\)\/",
RegexOptions.Compiled | RegexOptions.IgnoreCase);
string retval = null;
Match match = matcher.Match(path);
if (match.Groups.Count > 1)
{
retval = match.Groups[1].Value;
path = path.Substring(match.Groups[0].Index + match.Groups[0].Length);
}
return retval;
}
public void OnBeginRequest(object sender, EventArgs e)
{
HttpContext ctx = ((HttpApplication)sender).Context;
HttpRequest req = ctx.Request;
HttpResponse rep = ctx.Response;
string path = req.Path.Substring(req.ApplicationPath.Length);
string id = GetMunge(ref path);
bool cookieless = false;
bool rewrite = false;
if (id != null)
{
cookieless = true;
rewrite = true;
}
else if (path.StartsWith("cookietest"))
{
path = path.Substring("cookietest".Length);
rewrite = true;
HttpCookie cookie = req.Cookies["SessionIDCookieNameGoesHere"];
if (cookie != null)
id = cookie.Value;
else
cookieless = true;
}
ctx.Items["Cookieless"] = cookieless;
if (id != null)
{
// Get the existing session from the data cache.
Hashtable session = ctx.Cache[id] as Hashtable;
if (session == null)
{
// We got here with a session id, but there is no
// session associated with it. That means the id
// is either spoofed or expired. How you handle
// this is up to you.
}
else
{
ctx.Items["MySessionID"] = id;
ctx.Items["MySession"] = session;
}
}
else
{
// Create a new hashtable to store our session.
Hashtable session = new Hashtable();
Guid guid = Guid.NewGuid();
// Store the hashtable in the data cache with a 20-minute sliding
expiration.
ctx.Cache.Add(guid.ToString("N"), session, null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
new TimeSpan(0, 20, 0), System.Web.Caching.CacheItemPriority.Default,
null);
if (cookieless)
{
ctx.Items["MySessionID"] = guid.ToString("N");
ctx.Items["MySession"] = session;
}
else
{
HttpCookie cookie = new HttpCookie("SessionIDCookieNameGoesHere",
guid.ToString("N"));
rep.Redirect(req.ApplicationPath + "cookietest" + path, true);
rewrite = false;
}
}
if (rewrite)
ctx.RewritePath(req.ApplicationPath + path);
}
That gives you the basic session mechanism. Unfortunately, you can't mess
with the native ASP.NET session object exposed through Page.Session;
instead, you access this session through
((Hashtable)Page.Context.Items["MySession"]), which I admit is pretty
clunky. Also, remember that whenever you write data to this hashtable you'll
need to surround it in a lock() block, since web applications are
multithreaded. Other than that, though, you can just use the hashtable the
same way you'd use the HttpSessionState object.
The next trick is that, if you're in cookieless mode, you have to munge
every URL you write. To be honest, I'm not sure how ASP.NET does this; I
suspect it's pulling a stunt with fake application paths. My own project is
a content management system, so I generate every URL from code and just do
the munge at that point. A simple function to munge an URL would look like
this:
public string MungeRelativeURL(HttpContext ctx, string url)
{
if (ctx.Items["Cookieless"] != null && (bool)ctx.Items["Cookieless"] ==
true)
return "(" + (string)ctx.Items["MySessionID"] + ")/" + url;
else
return url;
}
There's one final problem I can't help you with. The whole point of this
exercise for you is to provide session information to the
FormsAuthentication module. However, that module is looking in the
Page.Session object as discussed above, and to the best of my knowledge
there's no way to change that. So what you'll have to do is hook the
FormsAuthentication_OnAuthenticate event and get the authentication ticket's
encrypted string out of your own session hashtable. Since I've never worked
with Forms Authentication, I don't have any advice to offer about that,
except that the IBuySpy example (www.ibuyspy.com) does something similar
that you can look at.
Hope this helps!
--Stephen Beeman
Beemania.com
Austin, TX
|
|
| |
|
| |
| Julian Voelcker |
Thanks TC, however I am actually finding that an increasing number of
individuals and companies are actually blocking cookies - pure paranoia on
there side, but it's something we have to take into account.
I suspected that an IHttpModule would be the way to go, so will investigate
further.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Wed, 22 May 2002 13:25:12 -0500, wrote:
[Original message clipped]
|
|
| |
|
| |
| Julian Voelcker |
Wow!
Thanks a lot Steve for all that, it's going to take me a while to
digest.
When in Cookieless mode, wont ASP.net be passing the session ID across
in the URLs automatically, or are we bypassing these functions?
Like you, I'm using the code for a site that has a Content Management
facility behind the scenes.
Looking through the code I think that it is going to take me a lot
longer to resolve than I have and it may just be quicker to do the
authentication as I would with old ASP.
I'll spend a day on it next week to see what I can come up with.
It's disappointing that MS didn't think of the cookieless problems when
they developed Forms Authentication - it is such an obvious problem.
Thank you again for your help on this.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
|
|
| |
|
| |
| ToddC@match.com |
Wow, we have been looking at the 25 million hits we get a day and have found
that users coming to our site, like 98% (Preliminary figure) of them, allow
cookies.
Try logging into some of the major sites while setting your browser to
prompt for each cookie. It gets annoying, but gives you a really good idea
how much you "need" cookies.
Lots of big sites won't work if people reject cookies. They just keep
refereeing you back to a login page.
This is probably acceptable for sites that require you to login, but for
general browsing another option should be looked into.
I much prefer putting it into ViewState over URL Munging. At least with
that you don't have to re-write all the links that point back to your site.
Good luck! Writing HTTPModules is really fun, don't let me talk you out of
it, dive in the water is great <g>.
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Thursday, May 23, 2002 3:16 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Thanks TC, however I am actually finding that an increasing number of
individuals and companies are actually blocking cookies - pure paranoia on
there side, but it's something we have to take into account.
I suspected that an IHttpModule would be the way to go, so will investigate
further.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Wed, 22 May 2002 13:25:12 -0500, wrote:
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Julian Voelcker |
The whole cookie thing is a pain. I know that it is only a small percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious facilities
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install their
blocking of cookies renders many sites unusable and that includes sites using
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a day -
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who tend
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
[Original message clipped]
|
|
| |
|
| |
| ToddC@match.com |
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25 million
is for a week, and I can not tell you why PR seems to think that reporting
for a week is the norm. Average a day for a week maybe. I verified just
over 3 million hits for Tuesday this week which is a slow day for us. These
are real page counts and not images etc. 3 times 7 - 21, plus a little for
peak times = 25 million. Sorry for the miss representation...
This is primarily a US site, but we do not exclude International users. We
do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more data
on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if you
are writing your own. I wonder if you can turn ViewState off in the page
directive, but still use it in an HTTPModule? Probably not, but would be
cool if you could. I have verified that the __ViewState hidden field is
passed even when ViewState is turned off, but haven't verified that I can
still use it. The only reason I think it may be useable is that it looks
like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install their
blocking of cookies renders many sites unusable and that includes sites
using
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a day
-
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Stephen Beeman |
> I wonder if you can turn ViewState off in the page directive, but still
use it in an HTTPModule?
> Probably not, but would be cool if you could.
You can create your own ViewState-like field very easily. It doesn't even
have to be a field; I use this mechanism all the time for passing
semi-secure information through URLs, which is more convenient for my task.
The string stored in __ViewState is generated by an undocumented class
called LosFormatter. This code generates a ViewState string:
object obj = AnyObjectYouWant;
LosFormatter output = new LosFormatter();
StringWriter writer = new StringWriter();
output.Serialize(writer, obj);
string viewstate = writer.ToString();
...and this code reconstitutes obj:
LosFormatter input = new LosFormatter();
obj = input.Deserialize(viewstate);
Though undocumented, LosFormatter is fairly safe to use, because if Redmond
ever breaks the API for it you can roll your own with about ten minutes
work. What LosFormatter.Serialize does is hash the binary object using one
of .NET's outstanding crypto classes, then encode it into Base64 using
XmlTextWriter.WriteBase64; LosFormatter.Deserialize just reverses that with
XmlTextReader.ReadBase64. (Note that Base64 uses two URL-unsafe characters,
so if you want to pass the results in a query string you'll need to replace
those using a regex.)
--Stephen Beeman
Beemania.com
|
|
| |
|
| |
| ToddC@match.com |
I'm not worried about hashing it; I want to make sure I don't have to
manually create a hidden control on each page in my app.
If I can "plug" into functionality that is already available on each page,
then that makes implementing my own session key passing mechanism easier to
implement on an existing site.
So, what I am looking for is a method to pass data to the client, that gets
resent on each request. Cookies are one way, but the media has created
quite a stir with them, and now we have tools such as ZoneAlarm to "block"
them. ViewState gets reposted with each post back and may be a good
alternative to cookies, at least for this. However, I disable ViewState on
a lot of pages that don't need it. That sort of makes it unavailable,
therefore not doable...
tc
-----Original Message-----
From: Stephen Beeman [mailto:Click here to reveal e-mail address]
Sent: Friday, May 24, 2002 1:32 PM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
> I wonder if you can turn ViewState off in the page directive, but still
use it in an HTTPModule?
> Probably not, but would be cool if you could.
You can create your own ViewState-like field very easily. It doesn't even
have to be a field; I use this mechanism all the time for passing
semi-secure information through URLs, which is more convenient for my task.
The string stored in __ViewState is generated by an undocumented class
called LosFormatter. This code generates a ViewState string:
object obj = AnyObjectYouWant;
LosFormatter output = new LosFormatter();
StringWriter writer = new StringWriter();
output.Serialize(writer, obj);
string viewstate = writer.ToString();
...and this code reconstitutes obj:
LosFormatter input = new LosFormatter();
obj = input.Deserialize(viewstate);
Though undocumented, LosFormatter is fairly safe to use, because if Redmond
ever breaks the API for it you can roll your own with about ten minutes
work. What LosFormatter.Serialize does is hash the binary object using one
of .NET's outstanding crypto classes, then encode it into Base64 using
XmlTextWriter.WriteBase64; LosFormatter.Deserialize just reverses that with
XmlTextReader.ReadBase64. (Note that Base64 uses two URL-unsafe characters,
so if you want to pass the results in a query string you'll need to replace
those using a regex.)
--Stephen Beeman
Beemania.com
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| ToddC@match.com |
Update, I consulted with the DataWhorehouse(er.. Warehouse) guys and they
say I was looking at the traffic for "Affiliates". We allow other web
masters to put links on their sites (heard this before eh?) Anyhow, we get
around 3 to 4 million hits a day from affiliates, and 20-22 million hits
direct domain. Per DAY!!!!
We have 150 web servers, and 8 Database servers. No COM, all ASP on Windows
2000 IIS 5.
With this load, we break crap that surprises Microsoft!
Tc
-----Original Message-----
From: Todd Carrico
Sent: Friday, May 24, 2002 10:02 AM
To: 'aspnghttphandlers'
Subject: RE: [aspnghttphandlers] Re: Changing Session state per user
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25 million
is for a week, and I can not tell you why PR seems to think that reporting
for a week is the norm. Average a day for a week maybe. I verified just
over 3 million hits for Tuesday this week which is a slow day for us. These
are real page counts and not images etc. 3 times 7 - 21, plus a little for
peak times = 25 million. Sorry for the miss representation...
This is primarily a US site, but we do not exclude International users. We
do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more data
on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if you
are writing your own. I wonder if you can turn ViewState off in the page
directive, but still use it in an HTTPModule? Probably not, but would be
cool if you could. I have verified that the __ViewState hidden field is
passed even when ViewState is turned off, but haven't verified that I can
still use it. The only reason I think it may be useable is that it looks
like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install their
blocking of cookies renders many sites unusable and that includes sites
using
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a day
-
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Julian Voelcker |
Wow, that's a lot.
After having consulted with a number of people I've decided to take your
approach and just insist on cookies since it's in the visitors interest to use
them.
On Wed, 29 May 2002 09:01:59 -0500, wrote:
[Original message clipped]
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
|
|
| |
|
| |
| ToddC@match.com |
For grins, what is your audience?
Ours is simple, Singles (course we get spammer, voyeurs etc.) but for the
most part I am betting that most of our users don't know what a cookie is or
how to turn them off. If our audience were more like say a Unix/Linux group
(I just find a lot of these "people" to be eccentric and maybe a little
paranoid) we might have a higher percentage of people turning them off. We
use a database session obviously, and AllowCookies is one of the things we
report on for this reason.
Your comment about firewalls and other apps that block them is worth noting,
also that this could be a cultural issue as well.
I'll see if I can get some numbers and get permission to post them
(bureaucracy eh?)
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 29, 2002 10:54 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Wow, that's a lot.
After having consulted with a number of people I've decided to take your
approach and just insist on cookies since it's in the visitors interest to
use
them.
On Wed, 29 May 2002 09:01:59 -0500, wrote:
[Original message clipped]
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Julian Voelcker |
The site I am working on is specifically targeted at charities, but
they are paying for the service so we have a bit more leverage over
them.
The problem we face is a high number of Mac users and users with older
browsers.
Why are you storing the session in a database? Is there any advantage?
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Wed, 29 May 2002 15:40:20 -0500, wrote:
[Original message clipped]
|
|
| |
|
| |
| Susan Warren |
Wow, super-interesting thread :) Go go go on those 22M requests per day
Todd!
The basic purpose of viewstate is to restore the current UI state of the
page on post back. In addition you can store your own page-scoped state
values into viewstate, however to retain session state information
beyond the scope of a single page you are going to have to put it
somewhere else, like Session State.
I agree that cookies are both very useful and often problematic.
ASP.NET has a feature called cookieless session state that does the same
trick Todd mentions below: it puts the session ID in the URL. It's just
a configuration setting; otherwise the use of Session State is the same
from the programming and operations perspectives. Works fine with Web
Farm Session State. Gory details about ASP.NET Session State at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp12282000.asp
Re what's going on with ViewState: Setting EnableViewState to false
tells controls not to persist their viewstate, however the page itself
still persists a few bytes that are basically a hash of the control
heirarchy for the page. If you don't plan to postback to the page you
can easily and completely disable viewstate by removing the <form
runat=3Dserver> element. Gory details about ViewState at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp11222001.asp
I don't see how you can use ViewState in any meaningful way from an
HttpModule however. The ViewState bag is populated in one of the
processing phases of the Page class _after_ the request has been passed
to the page handler. Getting to session state from a module is
possible, however.
Hth
Susan
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]=20
Sent: Wednesday, May 29, 2002 7:02 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Update, I consulted with the DataWhorehouse(er.. Warehouse) guys and
they say I was looking at the traffic for "Affiliates". We allow other
web masters to put links on their sites (heard this before eh?) Anyhow,
we get around 3 to 4 million hits a day from affiliates, and 20-22
million hits direct domain. Per DAY!!!!
We have 150 web servers, and 8 Database servers. No COM, all ASP on
Windows 2000 IIS 5.
With this load, we break crap that surprises Microsoft!
Tc
-----Original Message-----
From: Todd Carrico=20
Sent: Friday, May 24, 2002 10:02 AM
To: 'aspnghttphandlers'
Subject: RE: [aspnghttphandlers] Re: Changing Session state per user
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25
million is for a week, and I can not tell you why PR seems to think that
reporting for a week is the norm. Average a day for a week maybe. I
verified just over 3 million hits for Tuesday this week which is a slow
day for us. These are real page counts and not images etc. 3 times 7 -
21, plus a little for peak times =3D 25 million. Sorry for the miss
representation...
This is primarily a US site, but we do not exclude International users.
We do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more
data on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if
you are writing your own. I wonder if you can turn ViewState off in the
page directive, but still use it in an HTTPModule? Probably not, but
would be cool if you could. I have verified that the __ViewState hidden
field is passed even when ViewState is turned off, but haven't verified
that I can still use it. The only reason I think it may be useable is
that it looks like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]=20
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small
percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities=20
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install
their=20
blocking of cookies renders many sites unusable and that includes sites
using=20
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a
day
-=20
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend=20
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives
|
|
| |
|
| |
| ToddC@match.com |
150 web servers in a farm. No other way to do sessions that I know of.
Keep in mind this is ASP.OLD. We also have a data warehouse that we have
built to analyze click paths etc. Very cool stuff....
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Thursday, May 30, 2002 2:10 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The site I am working on is specifically targeted at charities, but
they are paying for the service so we have a bit more leverage over
them.
The problem we face is a high number of Mac users and users with older
browsers.
Why are you storing the session in a database? Is there any advantage?
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Wed, 29 May 2002 15:40:20 -0500, wrote:
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| ToddC@match.com |
Thanks for jumping in!!
I was speaking hypothetically about trying to use ViewState instead of
URL/Cookies. I was assuming that since you have access to the
Context.Request object, you could read from the ViewState. Obviously
haven't tried it.
I have come up with some pretty cool features however that you may find a
little interesting. I spoke at the aspNET PRO conference a few weeks ago
where I built a custom session object. Mostly an exercise in creating an
HttpModule, but the interesting thing was the inadvertent robustness that I
ended up with.
What I did was create a light weight data class that had properties that
matched up with the "Session Variables" my app needs. This class had one
method to persist its data in a SQL Database. No objects, just strings and
integers.
I configured the Web Application with the default session state, and wrote
an HttpModule to instantiate the custom session class in the
AcquireRequestState event. This lets the built in Session object create and
manage SessionID's for me, (either Cookieless or defult using Cookies). I
then use the SessionID to lookup the data in a DataBase to populate the
session object (my Data class) with. A reference to this object is then
placed into the Contents.Items collection which makes it available to the
page. On the ReleaseRequestState event the class's persist method is fired
to "Save the data".
I now have an object that persist it's data in a database, and retrieves it,
maintaining session state. All this work, and so far I have only duplicated
Microsoft's DataBase sessions, with the restriction that I cannot put
Objects into session state, and my object is a little harder to use than the
built in session bits. Seems like a step backwards...
What I found was that with this setup, I could restart the worker process,
without loosing session data. The data is persisted in the database, and as
long as the user has a SessionID, I can get the session data. If a User has
a SessionID, either cookie or URL, Microsoft just uses it even if it can't
find a "Match" in its pool of session ID's.
My data is not in TempDB, but is in a User DataBase, with tables and columns
that matchup with my data class. Now I have a very good replacement for IIS
Web Logs, that I can warehouse, query, incorporate with error logs etc.
This is something that you cannot do with the current Microsoft
implementation.
I can now bounce web servers, database servers, etc. all without loosing
session data. I also don't have to timeout a users session if I don't want
to.
I can farm this solution without having to use a State Service, and it will
scale to my current 25 million hits a day. Each web server is configured
for InProc as they hand out guids so no need to "coordinate" this between
servers.
What would be cool from here would be to "adjust" on the fly the ability to
use Cookies or URL session. Another option is to side step this and use
something like ViewState, that gets me around cookies, but doesn't present
the security implications of maintaining SessionID's in URL's. All browsers
that I know of understand "POST"...
Thanks for the links, hope I'm not boring any one.
tc
-----Original Message-----
From: Susan Warren [mailto:Click here to reveal e-mail address]
Sent: Thursday, May 30, 2002 9:45 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Wow, super-interesting thread :) Go go go on those 22M requests per day
Todd!
The basic purpose of viewstate is to restore the current UI state of the
page on post back. In addition you can store your own page-scoped state
values into viewstate, however to retain session state information
beyond the scope of a single page you are going to have to put it
somewhere else, like Session State.
I agree that cookies are both very useful and often problematic.
ASP.NET has a feature called cookieless session state that does the same
trick Todd mentions below: it puts the session ID in the URL. It's just
a configuration setting; otherwise the use of Session State is the same
from the programming and operations perspectives. Works fine with Web
Farm Session State. Gory details about ASP.NET Session State at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp12282000.asp
Re what's going on with ViewState: Setting EnableViewState to false
tells controls not to persist their viewstate, however the page itself
still persists a few bytes that are basically a hash of the control
heirarchy for the page. If you don't plan to postback to the page you
can easily and completely disable viewstate by removing the <form
runat=server> element. Gory details about ViewState at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp11222001.asp
I don't see how you can use ViewState in any meaningful way from an
HttpModule however. The ViewState bag is populated in one of the
processing phases of the Page class _after_ the request has been passed
to the page handler. Getting to session state from a module is
possible, however.
Hth
Susan
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 29, 2002 7:02 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Update, I consulted with the DataWhorehouse(er.. Warehouse) guys and
they say I was looking at the traffic for "Affiliates". We allow other
web masters to put links on their sites (heard this before eh?) Anyhow,
we get around 3 to 4 million hits a day from affiliates, and 20-22
million hits direct domain. Per DAY!!!!
We have 150 web servers, and 8 Database servers. No COM, all ASP on
Windows 2000 IIS 5.
With this load, we break crap that surprises Microsoft!
Tc
-----Original Message-----
From: Todd Carrico
Sent: Friday, May 24, 2002 10:02 AM
To: 'aspnghttphandlers'
Subject: RE: [aspnghttphandlers] Re: Changing Session state per user
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25
million is for a week, and I can not tell you why PR seems to think that
reporting for a week is the norm. Average a day for a week maybe. I
verified just over 3 million hits for Tuesday this week which is a slow
day for us. These are real page counts and not images etc. 3 times 7 -
21, plus a little for peak times = 25 million. Sorry for the miss
representation...
This is primarily a US site, but we do not exclude International users.
We do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more
data on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if
you are writing your own. I wonder if you can turn ViewState off in the
page directive, but still use it in an HTTPModule? Probably not, but
would be cool if you could. I have verified that the __ViewState hidden
field is passed even when ViewState is turned off, but haven't verified
that I can still use it. The only reason I think it may be useable is
that it looks like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small
percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install
their
blocking of cookies renders many sites unusable and that includes sites
using
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a
day
-
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
| |
| Susan Warren |
> inadvertent robustness
Gotta love it.
It was our intention to make the session state (and other
httpmodule-based functionality of ASP.NET) "hookable" in exactly the way
you describe, so users could extend or substitute to exactly meet their
needs.
One thought about the limitations of your current direction... have you
tried just modifying the SQL scripts that ship with ASP.NET to use
permanent (vs. Temporary) DB tables? As long as the schema and names
stay the same this works fine, and does give you a version of DB session
state that will survive downing the database boxes.
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]=20
Sent: Thursday, May 30, 2002 9:14 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Thanks for jumping in!!
I was speaking hypothetically about trying to use ViewState instead of
URL/Cookies. I was assuming that since you have access to the
Context.Request object, you could read from the ViewState. Obviously
haven't tried it.
I have come up with some pretty cool features however that you may find
a
little interesting. I spoke at the aspNET PRO conference a few weeks
ago
where I built a custom session object. Mostly an exercise in creating
an
HttpModule, but the interesting thing was the inadvertent robustness
that I
ended up with.
What I did was create a light weight data class that had properties that
matched up with the "Session Variables" my app needs. This class had
one
method to persist its data in a SQL Database. No objects, just strings
and
integers.
I configured the Web Application with the default session state, and
wrote
an HttpModule to instantiate the custom session class in the
AcquireRequestState event. This lets the built in Session object create
and
manage SessionID's for me, (either Cookieless or defult using Cookies).
I
then use the SessionID to lookup the data in a DataBase to populate the
session object (my Data class) with. A reference to this object is then
placed into the Contents.Items collection which makes it available to
the
page. On the ReleaseRequestState event the class's persist method is
fired
to "Save the data".
I now have an object that persist it's data in a database, and retrieves
it,
maintaining session state. All this work, and so far I have only
duplicated
Microsoft's DataBase sessions, with the restriction that I cannot put
Objects into session state, and my object is a little harder to use than
the
built in session bits. Seems like a step backwards...
What I found was that with this setup, I could restart the worker
process,
without loosing session data. The data is persisted in the database,
and as
long as the user has a SessionID, I can get the session data. If a User
has
a SessionID, either cookie or URL, Microsoft just uses it even if it
can't
find a "Match" in its pool of session ID's.
My data is not in TempDB, but is in a User DataBase, with tables and
columns
that matchup with my data class. Now I have a very good replacement for
IIS
Web Logs, that I can warehouse, query, incorporate with error logs etc.
This is something that you cannot do with the current Microsoft
implementation.
I can now bounce web servers, database servers, etc. all without loosing
session data. I also don't have to timeout a users session if I don't
want
to.
I can farm this solution without having to use a State Service, and it
will
scale to my current 25 million hits a day. Each web server is
configured
for InProc as they hand out guids so no need to "coordinate" this
between
servers.
What would be cool from here would be to "adjust" on the fly the ability
to
use Cookies or URL session. Another option is to side step this and use
something like ViewState, that gets me around cookies, but doesn't
present
the security implications of maintaining SessionID's in URL's. All
browsers
that I know of understand "POST"...
Thanks for the links, hope I'm not boring any one.
tc
-----Original Message-----
From: Susan Warren [mailto:Click here to reveal e-mail address]=20
Sent: Thursday, May 30, 2002 9:45 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Wow, super-interesting thread :) Go go go on those 22M requests per day
Todd!
The basic purpose of viewstate is to restore the current UI state of the
page on post back. In addition you can store your own page-scoped state
values into viewstate, however to retain session state information
beyond the scope of a single page you are going to have to put it
somewhere else, like Session State.
I agree that cookies are both very useful and often problematic.
ASP.NET has a feature called cookieless session state that does the same
trick Todd mentions below: it puts the session ID in the URL. It's just
a configuration setting; otherwise the use of Session State is the same
from the programming and operations perspectives. Works fine with Web
Farm Session State. Gory details about ASP.NET Session State at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp12282000.asp
Re what's going on with ViewState: Setting EnableViewState to false
tells controls not to persist their viewstate, however the page itself
still persists a few bytes that are basically a hash of the control
heirarchy for the page. If you don't plan to postback to the page you
can easily and completely disable viewstate by removing the <form
runat=3Dserver> element. Gory details about ViewState at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp11222001.asp
I don't see how you can use ViewState in any meaningful way from an
HttpModule however. The ViewState bag is populated in one of the
processing phases of the Page class _after_ the request has been passed
to the page handler. Getting to session state from a module is
possible, however.
Hth
Susan
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]=20
Sent: Wednesday, May 29, 2002 7:02 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Update, I consulted with the DataWhorehouse(er.. Warehouse) guys and
they say I was looking at the traffic for "Affiliates". We allow other
web masters to put links on their sites (heard this before eh?) Anyhow,
we get around 3 to 4 million hits a day from affiliates, and 20-22
million hits direct domain. Per DAY!!!!
We have 150 web servers, and 8 Database servers. No COM, all ASP on
Windows 2000 IIS 5.
With this load, we break crap that surprises Microsoft!
Tc
-----Original Message-----
From: Todd Carrico=20
Sent: Friday, May 24, 2002 10:02 AM
To: 'aspnghttphandlers'
Subject: RE: [aspnghttphandlers] Re: Changing Session state per user
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25
million is for a week, and I can not tell you why PR seems to think that
reporting for a week is the norm. Average a day for a week maybe. I
verified just over 3 million hits for Tuesday this week which is a slow
day for us. These are real page counts and not images etc. 3 times 7 -
21, plus a little for peak times =3D 25 million. Sorry for the miss
representation...
This is primarily a US site, but we do not exclude International users.
We do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more
data on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if
you are writing your own. I wonder if you can turn ViewState off in the
page directive, but still use it in an HTTPModule? Probably not, but
would be cool if you could. I have verified that the __ViewState hidden
field is passed even when ViewState is turned off, but haven't verified
that I can still use it. The only reason I think it may be useable is
that it looks like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]=20
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small
percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities=20
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install
their=20
blocking of cookies renders many sites unusable and that includes sites
using=20
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a
day
-=20
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend=20
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives
|
|
| |
|
| |
| ToddC@match.com |
Thought about that, just can't use that info in my Data Warehouse. If
warehousing the session data is not a concern, then modifying the script
would be the way to go.
Another approach might be to fire a sproc using an Async Delegate to put
data in my warehouse, and use the built in DB session state for the _real_
session work. This would separate the two "Functions", which may allow for
more flexibility. Best of both worlds, and the Delegate would keep the
"Log" hit from interfering with the Request/Response path.
I want to emphasize that this was an academic exercise, not one that I had a
business case for. Think maybe I beat this to death ;)
I mean to look harder at what the DB session actually does, how often they
are called per request, what actually goes on behind the scenes. I'll dive
into that next week and maybe post anything interesting. Thanks for the
dialog, I really appreciate your time.
tc
-----Original Message-----
From: Susan Warren [mailto:Click here to reveal e-mail address]
Sent: Friday, May 31, 2002 11:11 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
> inadvertent robustness
Gotta love it.
It was our intention to make the session state (and other
httpmodule-based functionality of ASP.NET) "hookable" in exactly the way
you describe, so users could extend or substitute to exactly meet their
needs.
One thought about the limitations of your current direction... have you
tried just modifying the SQL scripts that ship with ASP.NET to use
permanent (vs. Temporary) DB tables? As long as the schema and names
stay the same this works fine, and does give you a version of DB session
state that will survive downing the database boxes.
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]
Sent: Thursday, May 30, 2002 9:14 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Thanks for jumping in!!
I was speaking hypothetically about trying to use ViewState instead of
URL/Cookies. I was assuming that since you have access to the
Context.Request object, you could read from the ViewState. Obviously
haven't tried it.
I have come up with some pretty cool features however that you may find
a
little interesting. I spoke at the aspNET PRO conference a few weeks
ago
where I built a custom session object. Mostly an exercise in creating
an
HttpModule, but the interesting thing was the inadvertent robustness
that I
ended up with.
What I did was create a light weight data class that had properties that
matched up with the "Session Variables" my app needs. This class had
one
method to persist its data in a SQL Database. No objects, just strings
and
integers.
I configured the Web Application with the default session state, and
wrote
an HttpModule to instantiate the custom session class in the
AcquireRequestState event. This lets the built in Session object create
and
manage SessionID's for me, (either Cookieless or defult using Cookies).
I
then use the SessionID to lookup the data in a DataBase to populate the
session object (my Data class) with. A reference to this object is then
placed into the Contents.Items collection which makes it available to
the
page. On the ReleaseRequestState event the class's persist method is
fired
to "Save the data".
I now have an object that persist it's data in a database, and retrieves
it,
maintaining session state. All this work, and so far I have only
duplicated
Microsoft's DataBase sessions, with the restriction that I cannot put
Objects into session state, and my object is a little harder to use than
the
built in session bits. Seems like a step backwards...
What I found was that with this setup, I could restart the worker
process,
without loosing session data. The data is persisted in the database,
and as
long as the user has a SessionID, I can get the session data. If a User
has
a SessionID, either cookie or URL, Microsoft just uses it even if it
can't
find a "Match" in its pool of session ID's.
My data is not in TempDB, but is in a User DataBase, with tables and
columns
that matchup with my data class. Now I have a very good replacement for
IIS
Web Logs, that I can warehouse, query, incorporate with error logs etc.
This is something that you cannot do with the current Microsoft
implementation.
I can now bounce web servers, database servers, etc. all without loosing
session data. I also don't have to timeout a users session if I don't
want
to.
I can farm this solution without having to use a State Service, and it
will
scale to my current 25 million hits a day. Each web server is
configured
for InProc as they hand out guids so no need to "coordinate" this
between
servers.
What would be cool from here would be to "adjust" on the fly the ability
to
use Cookies or URL session. Another option is to side step this and use
something like ViewState, that gets me around cookies, but doesn't
present
the security implications of maintaining SessionID's in URL's. All
browsers
that I know of understand "POST"...
Thanks for the links, hope I'm not boring any one.
tc
-----Original Message-----
From: Susan Warren [mailto:Click here to reveal e-mail address]
Sent: Thursday, May 30, 2002 9:45 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Wow, super-interesting thread :) Go go go on those 22M requests per day
Todd!
The basic purpose of viewstate is to restore the current UI state of the
page on post back. In addition you can store your own page-scoped state
values into viewstate, however to retain session state information
beyond the scope of a single page you are going to have to put it
somewhere else, like Session State.
I agree that cookies are both very useful and often problematic.
ASP.NET has a feature called cookieless session state that does the same
trick Todd mentions below: it puts the session ID in the URL. It's just
a configuration setting; otherwise the use of Session State is the same
from the programming and operations perspectives. Works fine with Web
Farm Session State. Gory details about ASP.NET Session State at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp12282000.asp
Re what's going on with ViewState: Setting EnableViewState to false
tells controls not to persist their viewstate, however the page itself
still persists a few bytes that are basically a hash of the control
heirarchy for the page. If you don't plan to postback to the page you
can easily and completely disable viewstate by removing the <form
runat=server> element. Gory details about ViewState at:
http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp11222001.asp
I don't see how you can use ViewState in any meaningful way from an
HttpModule however. The ViewState bag is populated in one of the
processing phases of the Page class _after_ the request has been passed
to the page handler. Getting to session state from a module is
possible, however.
Hth
Susan
-----Original Message-----
From: Click here to reveal e-mail address [mailto:Click here to reveal e-mail address]
Sent: Wednesday, May 29, 2002 7:02 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
Update, I consulted with the DataWhorehouse(er.. Warehouse) guys and
they say I was looking at the traffic for "Affiliates". We allow other
web masters to put links on their sites (heard this before eh?) Anyhow,
we get around 3 to 4 million hits a day from affiliates, and 20-22
million hits direct domain. Per DAY!!!!
We have 150 web servers, and 8 Database servers. No COM, all ASP on
Windows 2000 IIS 5.
With this load, we break crap that surprises Microsoft!
Tc
-----Original Message-----
From: Todd Carrico
Sent: Friday, May 24, 2002 10:02 AM
To: 'aspnghttphandlers'
Subject: RE: [aspnghttphandlers] Re: Changing Session state per user
Yes, www.match.com. Last I heard we were pushing 25 million but after I
sent that, I had this feeling that was too much. Turns out that 25
million is for a week, and I can not tell you why PR seems to think that
reporting for a week is the norm. Average a day for a week maybe. I
verified just over 3 million hits for Tuesday this week which is a slow
day for us. These are real page counts and not images etc. 3 times 7 -
21, plus a little for peak times = 25 million. Sorry for the miss
representation...
This is primarily a US site, but we do not exclude International users.
We do have a UK site, uk.match.com. Not sure if that audience has a
proportionally higher number of users with them turned off or not. We
definitely need to look at this harder. We are trying to gather more
data on our audience, but I don't know if they are breaking this into
geographies.
FWIW, we put the SessionID in the URL. We do use cookies for other
functionality, but our session does not count on it.
I agree that cookies are a pain. ViewState may be a good alternative if
you are writing your own. I wonder if you can turn ViewState off in the
page directive, but still use it in an HTTPModule? Probably not, but
would be cool if you could. I have verified that the __ViewState hidden
field is passed even when ViewState is turned off, but haven't verified
that I can still use it. The only reason I think it may be useable is
that it looks like Microsoft uses it even if you set it to false.
Just rambling now...
tc
-----Original Message-----
From: Julian Voelcker [mailto:Click here to reveal e-mail address]
Sent: Friday, May 24, 2002 3:49 AM
To: aspnghttphandlers
Subject: [aspnghttphandlers] Re: Changing Session state per user
The whole cookie thing is a pain. I know that it is only a small
percentage
that have them disabled, but I think that it is on the increase.
Now that IE6 and firewall products like ZoneAlarm have more obvious
facilities
for blocking cookies, more people seem to be disabling them.
We use ZoneAlarm here in the office and even with the default install
their
blocking of cookies renders many sites unusable and that includes sites
using
Forms Authentication.
Out of interest, what site are you working on that gets 25million hits a
day
-
it is www.match.com.
The other problem we have is the site is targeted at the UK audience who
tend
to be a bit more cautious/paranoid about the Internet.
Cheers,
Julian Voelcker
The Virtual World (UK) Limited
Cirencester, United Kingdom
On Thu, 23 May 2002 13:23:24 -0500, wrote:
> Wow, we have been looking at the 25 million hits we get a day and have
found
> that users coming to our site, like 98% (Preliminary figure) of them,
allow
[Original message clipped]
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
| [aspnghttphandlers] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspnghttphandlers.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
|
|
| |
|
|
|
|
|
