ASP.Net design flaw!?

Discussion in 'ASP .Net' started by Kevin, Jan 22, 2004.

  1. Kevin

    Kevin Guest

    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, Jan 22, 2004
    #1
    1. Advertising

  2. Kevin

    Hans Kesting Guest

    "Kevin" <> wrote in message
    news:...
    > 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!


    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
     
    Hans Kesting, Jan 23, 2004
    #2
    1. Advertising

  3. Kevin

    Kevin Guest

    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.

    "Hans Kesting" <> wrote in message news:<>...
    > "Kevin" <> wrote in message
    > news:...
    > > 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!

    >
    > 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
     
    Kevin, Jan 23, 2004
    #3
  4. "Kevin" <> wrote in message
    news:...
    > 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,

    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.
    --
    John Saunders
    John.Saunders at SurfControl.com
     
    John Saunders, Jan 23, 2004
    #4
  5. Kevin

    Kevin Guest

    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?

    "John Saunders" <john.saunders at SurfControl.com> wrote in message news:<>...
    > "Kevin" <> wrote in message
    > news:...
    > > 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,
    >
    > 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.
     
    Kevin, Jan 27, 2004
    #5
  6. "Kevin" <> wrote in message
    news:...
    > 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.



    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.
    --
    John Saunders
    John.Saunders at SurfControl.com
     
    John Saunders, Jan 27, 2004
    #6
  7. Kevin

    Kevin Guest

    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


    "John Saunders" <john.saunders at SurfControl.com> wrote in message news:<#>...

    > 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.
     
    Kevin, Jan 27, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew
    Replies:
    0
    Views:
    465
    Andrew
    Jun 29, 2005
  2. Mr Smith
    Replies:
    0
    Views:
    370
    Mr Smith
    Mar 16, 2005
  3. Replies:
    0
    Views:
    426
  4. ma740988
    Replies:
    11
    Views:
    1,673
    ma740988
    Jul 29, 2004
  5. Daniel Silva

    Lambda: the Ultimate Design Flaw

    Daniel Silva, Apr 1, 2005, in forum: Python
    Replies:
    63
    Views:
    1,280
    Ron_Adam
    Apr 7, 2005
Loading...

Share This Page