web farm session sharing

Hi,
I am having a problem sharing session between SSL and non-SSL asp.net pages.
I have F5 BigIP with sticky sessions working fine, but the problem is that
sticky session applies at the port level (80 vs. 443) so when a user goes to
a SSL page I lose session vars because it's on another server on the farm.
When the user stays on the same server for both non-SSL and SSL the session
is shared OK.
Has anyone come across this problem and are there any work arounds?
Thanks,
DanielDaniel,
The best way to get around this is to use a Session State server. You can
either store the sessions in a state server or in SQL Server. You could even
define one of your web servers as the state server for the farm. I've had
good experience using SQL Server session state but not the state server. The
best part about is is that you can disable sticky sessions -- they are no
longer needed. By disabling sticky sessions, you make your system more fault
tolerant becuase a web server can go down without losing any session
information.
For more information see:
ASP.NET Session State
http://msdn.microsoft.com/library/d...>
12282000.asp
HTH,
Doug
"Daniel" <anonymous@.discussions.microsoft.com> wrote in message
news:010B877D-B984-4E59-BA54-7F9E283A1201@.microsoft.com...
> Hi,
> I am having a problem sharing session between SSL and non-SSL asp.net
pages.
> I have F5 BigIP with sticky sessions working fine, but the problem is that
> sticky session applies at the port level (80 vs. 443) so when a user goes
to
> a SSL page I lose session vars because it's on another server on the farm.
> When the user stays on the same server for both non-SSL and SSL the
session
> is shared OK.
> Has anyone come across this problem and are there any work arounds?
> Thanks,
> Daniel
>
I did look into session state, but the issue is the same that once the user
goes from SSL to non-SSL a new session is started under SSL.
Thanks,
-- Doug Perkes wrote: --
Daniel,
The best way to get around this is to use a Session State server. You can
either store the sessions in a state server or in SQL Server. You could even
define one of your web servers as the state server for the farm. I've had
good experience using SQL Server session state but not the state server. The
best part about is is that you can disable sticky sessions -- they are no
longer needed. By disabling sticky sessions, you make your system more fault
tolerant becuase a web server can go down without losing any session
information.
For more information see:
ASP.NET Session State
http://msdn.microsoft.com/library/d...>
12282000.asp
HTH,
Doug
"Daniel" <anonymous@.discussions.microsoft.com> wrote in message
news:010B877D-B984-4E59-BA54-7F9E283A1201@.microsoft.com...
> Hi,
pages.
> I have F5 BigIP with sticky sessions working fine, but the problem is that
> sticky session applies at the port level (80 vs. 443) so when a user goes
to
> a SSL page I lose session vars because it's on another server on the farm.
> When the user stays on the same server for both non-SSL and SSL the
session
> is shared OK.
>
One option is storing the session information in a central location that
all the servers have access to. ASP.NET supports dedicating a
centralized session state server, or storing the session state in Sql
Server. See this article:
http://msdn.microsoft.com/library/e...essionstate.asp
I've yet to try this in a production evironment though, so I'm not sure
how well it really scales.
-Jason
Daniel wrote:
> Hi,
> I am having a problem sharing session between SSL and non-SSL asp.net page
s.
> I have F5 BigIP with sticky sessions working fine, but the problem is that
> sticky session applies at the port level (80 vs. 443) so when a user goes
to
> a SSL page I lose session vars because it's on another server on the farm.
> When the user stays on the same server for both non-SSL and SSL the sessio
n
> is shared OK.
> Has anyone come across this problem and are there any work arounds?
> Thanks,
> Daniel
>
Daniel,
It is most likely that a new session is being started becuase the user is
getting sent to a new server. Since the new server doesn't recognize the
session id being sent to it, the web server creates a new session for the
user.
Since the user is being moved from HTTP (port 80) to HTTPS (port 443) the
load balancer treats it as new user and sends it to an arbitrary server.
-- doug
"Daniel" <anonymous@.discussions.microsoft.com> wrote in message
news:CC7A79F4-A3CD-4A39-9035-1D448BE5229A@.microsoft.com...
> I did look into session state, but the issue is the same that once
the user goes from SSL to non-SSL a new session is started under SSL.
> Thanks,
> -- Doug Perkes wrote: --
> Daniel,
> The best way to get around this is to use a Session State server. You
can
> either store the sessions in a state server or in SQL Server. You
could even
> define one of your web servers as the state server for the farm. I've
had
> good experience using SQL Server session state but not the state
server. The
> best part about is is that you can disable sticky sessions -- they
are no
> longer needed. By disabling sticky sessions, you make your system
more fault
> tolerant becuase a web server can go down without losing any session
> information.
> For more information see:
> ASP.NET Session State
>
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp[/u
rl]
> HTH,
> Doug
>
> "Daniel" <anonymous@.discussions.microsoft.com> wrote in message
> news:010B877D-B984-4E59-BA54-7F9E283A1201@.microsoft.com...
asp.net
> pages.
is that
user goes
> to
the farm.
> session
arounds?