Topics: Web Api
May 11, 2011 at 11:56 AM

Hi guys,

I'm trying to access the Session object in the httpcontext whenever a REST method is triggered (using preview 4).

However, the binding used in Preview 4 doesn't seem to support the aspnet compatibility. httpcontext.current isn't available.

And yes, even though REST is stateless we really need the session to keep some very expensive object in memory once retrieved from the database.

Any ideas? Am I doing something wrong?

Thx (again),


May 11, 2011 at 5:11 PM

Hi Gerben,

Have you considered caching as an alternative to managing session?

May 11, 2011 at 6:33 PM

Are you using ServiceRoute / hosted on ASP.NET?

May 11, 2011 at 9:24 PM


You really don't need to access the session object to get at global state.  Here's what I did as an experiment.

I created a class for holding server state


public class ServerState : ConcurrentDictionary<string, object> {


Then I created a ServerStateOperationHandler that can make the server state available as a parameter on my operation.


public class ServerStateOperationHandler : HttpOperationHandler {
        private readonly ServerState _State;

        public ServerStateOperationHandler(ServerState state) {
            _State = state;

        protected override IEnumerable<HttpParameter> OnGetInputParameters() {
            return null;

        protected override IEnumerable<HttpParameter> OnGetOutputParameters() {
            yield return new HttpParameter("serverState", typeof(ServerState));

        protected override object[] OnHandle(object[] input) {
            return new object[] {_State};


Each instance of the operation handler needs to be passed a copy of the global instance of the ServerState object, so in my OperationHandlerFactory I added code to do that



 public class OperationHandlerFactory : HttpOperationHandlerFactory {
        private ServerState _ServerState;
        public OperationHandlerFactory(ServerState serverState) {
            _ServerState = serverState;
        protected override System.Collections.ObjectModel.Collection<Microsoft.ApplicationServer.Http.Dispatcher.HttpOperationHandler> OnCreateRequestHandlers(System.ServiceModel.Description.ServiceEndpoint endpoint, HttpOperationDescription operation) {
            var collection = base.OnCreateRequestHandlers(endpoint, operation);
            collection.Add(new ServerStateOperationHandler(_ServerState));
            return collection;

        protected override System.Collections.ObjectModel.Collection<Microsoft.ApplicationServer.Http.Dispatcher.HttpOperationHandler> OnCreateResponseHandlers(System.ServiceModel.Description.ServiceEndpoint endpoint, HttpOperationDescription operation) {
            var collection = base.OnCreateResponseHandlers(endpoint, operation);
            collection.Add(new LoggingOperationHandler(new Logger()));
            return collection;


In order to test this, in my configuration code, I created some global state and passed it into my OperationHandlerFactory


	    var serverState = new ServerState();
            serverState["Hello"] = "World";
            var operationHandlerFactory = new OperationHandlerFactory(serverState);

            var config = HttpHostConfiguration.Create()
                .SetResourceFactory(new ResourceFactory(serviceLocator))



Now in order to access that state in an operation, I can simply add a ServerState parameter to the operation signature.

 	[WebGet(UriTemplate = "ServerState")]
        public HttpResponseMessage GetServerState(ServerState serverState) {

            var httpResponseMessage = new HttpResponseMessage();
            httpResponseMessage.StatusCode = HttpStatusCode.OK;
            httpResponseMessage.Content = new StringContent((string)serverState["Hello"], System.Text.Encoding.UTF8, "text/plain");
            return httpResponseMessage;

Does that make sense?

May 11, 2011 at 10:02 PM

Miller's idea is a good one, but be aware of security issues that could arise from keeping server objects in a hashtable.  

If the client can inject a different hashtable key that the one they are implicitly authorized to use then they could access objects from that server state that would otherwise be off limits to them..

May 11, 2011 at 10:31 PM

Just to add on this, you don't have to create custom factories. We also support an inline syntax for adding the handler.

var config = HttpHostConfiguration.Create()
  .AddRequestHandlers(new ServerStateOperationHandler());
May 11, 2011 at 11:10 PM

Damn.  I keep forgetting about these fancy schmancy new configuration features :-)  

May 11, 2011 at 11:13 PM

:-) :-) :-) :-) :-)

May 12, 2011 at 9:12 AM

wow, glenn, is that all?

I am indeed using ServiceRoute / hosted on ASP.NET.

Loved your talk in the Netherlands btw.

May 12, 2011 at 10:59 AM

Hi Darrel,

Thx for the input, the convenient part of Session is that it's garbage collected whenever the sessions times out. And also it implies the scope of the user only. Does ServerState offer me that?


May 12, 2011 at 1:29 PM

Hi Gerben,

I created the ServerState object out of a simple dictionary.  If you want more sophisticated caching capabilities then ServerState could use the Memory cache class or link to a more sophisticated caching system like the AppFabric caching service or Redis.  It you want to scope objects to a particular user then you would use some kind of user identifier as prefix on the cache key.  

Just be careful with using this type of caching.  As LJD said in many cases using regular HTTP caching can be a much better way to reduce server load.