Session Problems with Desktop Shortcuts in IE

[headware]

I have an issue that I've been encountering in an ASP application I'm
working on. Most of the application is written in ASP, but there is one
page written in ASP.NET. The ASP.NET page needs to have access to the
ASP Session data to run correctly. In order to achieve this I create my
own HTTP request for a certain ASP page with the name of Session
variable that I want is stored in the query string of the request. The
requested ASP page sends back the Session value in the response (you
can see more on this at
http://searchvb.techtarget.com/vsnet...93033,00.html).
This seems to work in general but we have noticed a few difficult to
reproduce problems with this.

When multiple instances of the web app are set up in different virtual
directories and the user creates desktop shortcuts to access each
installation, there appears to be problems with the Session data. When
the user opens up more than one shortcut at once, it looks as though
all the browsers are running under one IEXPLORE.EXE process. This would
explain things if the ASPSESSIONID cookie, which holds the ID for the
Session data to use for a particular user, is held in the shared
process. However, on different servers the Session bug is not always
reproducible. In other words if the user has a desktop shortcuts to
"http://Server1/app1/login.asp" and another to
"http://Server1/app2/login.asp", the Session accessing will have
problems. However if you do the same thing on a different server, that
is "http://Server2/app1/login.asp" and to
"http://Server2/app2/login.asp", the bug will *not* occur. The servers
are running different versions of Windows and IIS, so I'm sure that has
something to do with it, but I just can't figure out what.

Through some experimentation using FireFox and Live HTTP Headers, we
found that sometimes FireFox will contain two ASPSESSIONID cookies,
where the characters after "ASPSESSIONID", but before the '=' sign, are
different. Since both FireFox browsers were running in the same process
and yet somehow correctly handled the Session data, we assumed these
extra characters helped the server distinguish which Session data the
browser needed. However, these cookies have magically stopped appearing
(though FireFox still seems to handle the Session correctly). And I've
never gotten the multiple cookie thing to happen in IE.

Has anyone heard of this issue? Since people use desktop shortcuts
quite a bit, I would have expected this issue to have occurred a number
of times in the past, but I'm having trouble finding any info on it.

Dave

[Egbert Nierop \(MVP for IIS\)]

Hi,

You need a product, which manages the sessions itself there are several.
This one is hybrid, written using C++, and runs in ASP.NET and ASP..
The SessionID you mention, is even not unique per server. If you reset the
application, the session are regenerated and possibly are the same as
before.
The most fun is that ISP Session, allows to -resume- a session from a URL or
an email even if the browser was closed, totally.
http://www.nieropwebconsult.nl/resumedemo
--
compatible web farm Session replacement for Asp and Asp.Net
http://www.nieropwebconsult.nl/asp_session_manager.htm

"headware" <he******@aol.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I have an issue that I've been encountering in an ASP application I'm
working on. Most of the application is written in ASP, but there is one
page written in ASP.NET. The ASP.NET page needs to have access to the
ASP Session data to run correctly. In order to achieve this I create my
own HTTP request for a certain ASP page with the name of Session
variable that I want is stored in the query string of the request. The
requested ASP page sends back the Session value in the response (you
can see more on this at
http://searchvb.techtarget.com/vsnet...93033,00.html).
This seems to work in general but we have noticed a few difficult to
reproduce problems with this.

When multiple instances of the web app are set up in different virtual
directories and the user creates desktop shortcuts to access each
installation, there appears to be problems with the Session data. When
the user opens up more than one shortcut at once, it looks as though
all the browsers are running under one IEXPLORE.EXE process. This would
explain things if the ASPSESSIONID cookie, which holds the ID for the
Session data to use for a particular user, is held in the shared
process. However, on different servers the Session bug is not always
reproducible. In other words if the user has a desktop shortcuts to
"http://Server1/app1/login.asp" and another to
"http://Server1/app2/login.asp", the Session accessing will have
problems. However if you do the same thing on a different server, that
is "http://Server2/app1/login.asp" and to
"http://Server2/app2/login.asp", the bug will *not* occur. The servers
are running different versions of Windows and IIS, so I'm sure that has
something to do with it, but I just can't figure out what.

Through some experimentation using FireFox and Live HTTP Headers, we
found that sometimes FireFox will contain two ASPSESSIONID cookies,
where the characters after "ASPSESSIONID", but before the '=' sign, are
different. Since both FireFox browsers were running in the same process
and yet somehow correctly handled the Session data, we assumed these
extra characters helped the server distinguish which Session data the
browser needed. However, these cookies have magically stopped appearing
(though FireFox still seems to handle the Session correctly). And I've
never gotten the multiple cookie thing to happen in IE.

Has anyone heard of this issue? Since people use desktop shortcuts
quite a bit, I would have expected this issue to have occurred a number
of times in the past, but I'm having trouble finding any info on it.

Dave

[david.k.land]

Egbert,

Thanks for the reply. I'm not running multiple servers, but rather
multiple web apps on one server, so I'm not sure how much the tool you
mentioned would help.

After doing further testing I've noticed that the multiple ASPSESSIONID
cookie seems to occur at random but goes away after you reset IIS. For
instance, it started happening yesterday and I did an iisreset.exe and
it stopped. The weird thing is that whether there were more than one
ASPSESSIONID cookie or not, the Session was being managed properly by
IIS. It still somehow knew how to differentiate the Session for each
browser.

So I'm pretty confused at this point about the role that the multiple
ASPSESSIONID cookies play or why this whole issue in general seems to
come and go at random.

Dave

[Egbert Nierop \(MVP for IIS\)]

<da**********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Egbert,

Thanks for the reply. I'm not running multiple servers, but rather
multiple web apps on one server, so I'm not sure how much the tool you
mentioned would help.
That's the same Idea, that tool can help sharing the session.
After doing further testing I've noticed that the multiple ASPSESSIONID
cookie seems to occur at random but goes away after you reset IIS. For
instance, it started happening yesterday and I did an iisreset.exe and
it stopped. The weird thing is that whether there were more than one
ASPSESSIONID cookie or not, the Session was being managed properly by
IIS. It still somehow knew how to differentiate the Session for each
browser.
that's right. So I'm pretty confused at this point about the role that the multiple
ASPSESSIONID cookies play or why this whole issue in general seems to
come and go at random.
The idea is to create your own unique cookie and stick your session to it.
But then, you also need a way, to relate that to the session, which is not
possible with classic asp.

--
compatible web farm Session replacement for Asp and Asp.Net
http://www.nieropwebconsult.nl/asp_session_manager.htm
Dave