Session unavailable in PostAcquireRequestState/PreRequestHandlerExecute

[Flinky Wisty Pomm]

Hi all, I'm tearing my hair out here and I'm desperately hoping someone
has a fix.

I've got a .Net 2.0 web service for which I need session state, I can't
use cookies because I'm using the .NetCF, I used a cookieless session
and that was fine over Wi-Fi but borked horribly over GPRS, for which I
blame the ISP.

I implemented a quick hack with a SoapHeader containing the SessionId
and implemented a custom ISessionIDManager, now I just want to get some
data back out.

For reasons I'm unable to fathom, HttpContext.Session is unavailable
during PreRequestHandlerExecute. Even more bizarrely, the session is
unavailable during PostAcquireRequestState, the event that fires to
tell you that the session has been populated.

This issue affects .asmx and .axd files, but NOT aspx. The issue has
been raised before in posts going back (at least) to 2002 under the 1.0
framework.

The WebMethods involved all have EnableSession set to true and I can
access the session from the actual webservice, just not from any
application events that fire beforehand.

Does anybody have a workaround for this? I suppose I could drop the
session altogether and use the Application Cache to store a user's
credentials, but that's uglier than ugliness.

<code>

public class AuthenticateRequestHttpModule : IHttpModule
{
private HttpApplication _HttpApp;

public void Init(HttpApplication httpApp)
{
this._HttpApp = httpApp;
_HttpApp.PostAcquireRequestState+= new
EventHandler(AuthenticateFromSession);
}

protected void AuthenticateFromSession(object sender, EventArgs
e)
{
HttpContext context = (sender as HttpApplication).Context;
if(null == context.Session)
throw new Exception("Isn't this a _really_ silly bug?");
}

public void Dispose(){}

}

</code>

[Flinky Wisty Pomm]

Added the IRequiresSessionState marker interface. For some reason,
this seems to be required for non-aspx files in HttpModules, though it
worked without if I was access a web page.

I'd tried this before, but must have been handling an event too early
in the request lifecycle.