I realize session and REST don't exactly go hand in hand but is it not possible to access session state using the new Web API? HttpContext.Current.Session
is always null.
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- How to store image outside of the website's ro
- 'System.Threading.ThreadAbortException' in
- Request.PathInfo issues and XSS attacks
- How to dynamically load partial view Via jquery aj
相关文章
- asp.net HiddenField控件扩展问题
- asp.net HiddenField控件扩展问题
- Asp.Net网站无法写入错误日志,测试站点可以,正是站点不行
- asp.net mvc 重定向到vue hash字符串丢失
- FormsAuthenticationTicket expires too soon
- “Dynamic operations can only be performed in homog
- What is the best way to create a lock from a web a
- Add to htmlAttributes for custom ActionLink helper
To fix the issue:
in Global.asax.cs
Last one is not working now, take this one, it worked for me.
in WebApiConfig.cs at App_Start
Global.asax
fournd here: http://forums.asp.net/t/1773026.aspx/1
Mark, if you check the nerddinner MVC example the logic is pretty much the same.
You only need to retrieve the cookie and set it in the current session.
Global.asax.cs
You'll have to define your "SampleIdentity" class, which you can borrow from the nerddinner project.
You can access session state using a custom RouteHandler.
Found here: http://techhasnoboundary.blogspot.com/2012/03/mvc-4-web-api-access-session.html
I followed @LachlanB approach and indeed the session was available when the session cookie was present on the request. The missing part is how the Session cookie is sent to the client the first time?
I created a HttpModule which not only enabling the HttpSessionState availability but also sends the cookie to the client when a new session is created.
Why to avoid using Session in WebAPI?
Performance, performance, performance!
There's a very good, and often overlooked reason why you shouldn't be using Session in WebAPI at all.
The way ASP.NET works when Session is in use is to serialize all requests received from a single client. Now I'm not talking about object serialization - but running them in the order received and waiting for each to complete before running the next. This is to avoid nasty thread / race conditions if two requests each try to access Session simultaneously.
So what does this mean for Web API? If you have an application running many AJAX requests then only ONE is going to be able to run at a time. If you have a slower request then it will block all others from that client until it is complete. In some applications this could lead to very noticeably sluggish performance.
So you should probably use an MVC controller if you absolutely need something from the users session and avoid the unncesessary performance penalty of enabling it for WebApi.
You can easily test this out for yourself by just putting
Thread.Sleep(5000)
in a WebAPI method and enable Session. Run 5 requests to it and they will take a total of 25 seconds to complete. Without Session they'll take a total of just over 5 seconds.(This same reasoning applies to SignalR).