ASP.Net design flaw!?

  • Thread starter Thread starter Kevin
  • Start date Start date
K

Kevin

Has anyone ever encountered this problem? (I searched on google for
past posts but didn't find anything)

I have a class implementing the IHttpModule Interface. It's mainly
used for seting up layout information & provide some security/logging
functions. Typically it inspects a HttpRequest, set some variables
into session, and returns.

for exactness, the HttpModule is hooked up to these events

PreRequestHandlerExecute
PostRequestHandlerExecute

The strange thing is, depending on the content of the ASPX page that
the Http Request is for, sometimes HttpContext.Session is not
available for the HttpModule.

It turns out that if the targeted aspx page does not have any
code-behinds or scriptlet blocks.. or any code whatsoever. ASP.Net
creates a handler object for that request/aspx page which does not
implement IRequiresSessionState interface, hence no session.

Now that is fine since you would never need to access session info
from an aspx page that contains no code. But in my case.. the
HttpModule DOES..

So, given the problem stated.. I thought the way to solve it would be

override Page class and implement the IRequreSessionState Interface in
a new class.
specify the pageBaseType attribute in the pages directive under
web.config to the new class.

and of course it didn't work!! Can anyone suggest anything else?
(other than adding a code block to every single aspx page) or at least
explain why my work around is futile.

Any input will be greatly appreciated.

Thanks!
 
Kevin said:
Has anyone ever encountered this problem? (I searched on google for
past posts but didn't find anything)

I have a class implementing the IHttpModule Interface. It's mainly
used for seting up layout information & provide some security/logging
functions. Typically it inspects a HttpRequest, set some variables
into session, and returns.

for exactness, the HttpModule is hooked up to these events

PreRequestHandlerExecute
PostRequestHandlerExecute

The strange thing is, depending on the content of the ASPX page that
the Http Request is for, sometimes HttpContext.Session is not
available for the HttpModule.

It turns out that if the targeted aspx page does not have any
code-behinds or scriptlet blocks.. or any code whatsoever. ASP.Net
creates a handler object for that request/aspx page which does not
implement IRequiresSessionState interface, hence no session.

Now that is fine since you would never need to access session info
from an aspx page that contains no code. But in my case.. the
HttpModule DOES..

So, given the problem stated.. I thought the way to solve it would be

override Page class and implement the IRequreSessionState Interface in
a new class.
specify the pageBaseType attribute in the pages directive under
web.config to the new class.

and of course it didn't work!! Can anyone suggest anything else?
(other than adding a code block to every single aspx page) or at least
explain why my work around is futile.

Any input will be greatly appreciated.

Thanks!
Click to expand...

Can you check if HttpContext.Session != null ??
then you can skip your code-block if the requested page will not be able
to make use of it anyway.

Hans Kesting
 
Even though the requested page does not require Session info, in my
case, the HttpModule must record the url of the resource that the user
is accessing, and save that information into the SessionState. The
user's path through the application is then used to make decisions for
subsequent requests.
 
Kevin said:
Even though the requested page does not require Session info, in my
case, the HttpModule must record the url of the resource that the user
is accessing, and save that information into the SessionState. The
user's path through the application is then used to make decisions for
subsequent requests.
Click to expand...

Kevin,

I question this design. I gather that right now, the user signals a desire
to change state by clicking on links, which direct them to the page which
represents the state change? But why equate the path through the application
with the changes in the users state? What if, at a later date, you decide to
add a pop-up at some point, perhaps without changing the state?

Instead, why not have the link post back to the current page, and have the
page change the state then either use Response.Redirect or Server.Transfer
to go to the desired new page? That way, the page (which has Session
available) would be what changes the state. You wouldn't need an HttpModule
to translate URLs into state.
 
Hi John,

Thanks for your response, but I think we're getting off topic. I was
really hoping someone (Any MSFT employees??) could address the
technical aspect of how ASP.Net handles SessionState in the scenario
provided.

In all fairness, I should give more detail about what the HttpModule
is doing so that the question makes more sense! (Please see earlier
post in this thread for more info..)

We're trying to design our application so that it changes behavior
depending on what the user has seen. So if the user has viewed
certain pages, we will change the application to customize their
experience.

We opt not to use post backs or other server side events because this
is not supposed to be an intrusive function, the user is not actively
providing feedback. Instead, we want to quietly profile the path the
user is taking through our application and make display/marketing
decisions further down the process.

The problem is, some of these files along the way could be just simple
ASPX files with no scriplet blocks or any code whatsoever. In those
cases, SessionState is not created, and the HttpModule cannot
store/access any information from it.

Overriding the Page class and specifying a basePage type in the
web.config did not solve the problem. Leading me to believe ASP.Net
optimizes code-free ASPX pages by piping it straight out without
following the usual rules of ASPX page life cycle. That decision
doesn't really make sense to me.

Can someone provide a work-around without requiring that every single
ASPX be created with a scriptlet block?
 
Kevin said:
Hi John,

Thanks for your response, but I think we're getting off topic. I was
really hoping someone (Any MSFT employees??) could address the
technical aspect of how ASP.Net handles SessionState in the scenario
provided.

In all fairness, I should give more detail about what the HttpModule
is doing so that the question makes more sense! (Please see earlier
post in this thread for more info..)

We're trying to design our application so that it changes behavior
depending on what the user has seen. So if the user has viewed
certain pages, we will change the application to customize their
experience.

We opt not to use post backs or other server side events because this
is not supposed to be an intrusive function, the user is not actively
providing feedback. Instead, we want to quietly profile the path the
user is taking through our application and make display/marketing
decisions further down the process.
Click to expand...


Actually, my recommendation stands.

In order not to stray too far off-topic, I'll just ask you what you want
your application to do if the user creates a new browser window with, e.g.,
the IE File->New->Window command? I believe that the new window would share
session state with the original window, yet the user could use the new
window to browse a totally different path than the original. In general, the
sequence of requested URLs may not always give you what you want.

If the session cookie is available to your HttpModule, you might try using
it as the key into a hash table you store in Application state.
 
Hi John,

In our case, we want to know whether or not a user has seen a
particular banner/advertisement/content. If they have seen it at ANY
POINT during their visit to the site, we will show them a narrowed set
of offers/promotions when they request other pages from the site. The
order of visit is not important, just as long as they are logged.

So regardless of whether the user opens a new window or not.. As soon
as they come to any dynamic pages containing product offers, we will
make use of their session information to determine what offer to best
display to the user.

For example, if the user has seen a page containing information about
Sneakers, we want to show them promotions regarding sneakers in
prominent spots on other pages of the site.

Finally, yes, the session cookie is available to the HttpModule, and I
have considered using it to store variables.. basically re-creating
what SessionStateModule is already doing in AcquireRequestState. It
will work as long as we stay with cookie-based sessions... it just
seems like extra work that shouldn't be necessary in a well designed
app server.

Thanks,
Kevin
 
Back
Top