Why is HttpContext.Current null after await?

Question

I have the following test WebAPI code, I don't use WebAPI in production but I made this because of a discussion I had on this question: WebAPI Async question

Anyways, here's the offending WebAPI method:

public async Task<string> Get(int id)
{
    var x = HttpContext.Current;
    if (x == null)
    {
        // not thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    await Task.Run(() => { Task.Delay(500); id = 3; });

    x = HttpContext.Current;
    if (x == null)
    {
        // thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    return "value";
}

I had hereto believed that the second exception is expected because when the await completes, it will likely be on a different thread where HttpContext.Current as a thread-static variable will no longer resolve to the appropriate value. Now, based on the synchronization context, it could actually be forced to go back to the same thread after the await but I'm not doing anything fancy in my test. This is just a plain, naive use of await.

In comments in another question I was told that HttpContext.Current should resolve after an await. There's even another comment on this question indicating the same. So what's true? Should it resolve? I think no, but I want an authoritative answer on this because async and await is new enough that I can't find anything definitive.

TL;DR: Is HttpContext.Current potentially null after an await?

Your question is unclear - you've said what you expected to happen, and the comments indicate that that *is* what's happening... so what's confusing you? — Jon Skeet, Aug 22 '13 at 14:57
@user2674389, this is misleading. It's `AspNetSynchronizationContext` that takes care of `HttpContext`, not `await`. More, the continuation callback for `await` may (and most likely will) occur on a different thread for Web API execution model. — noseratio, Aug 22 '13 at 15:01
Don't use HttpContext in Web API. It isn't supported for all hosts. There are alternative ways to do what HttpContext is used for. — Darrel Miller, Aug 23 '13 at 01:13
Could you elaborate on what these alternative ways might be, @DarrelMiller? That would be useful... — Joep Beusenberg, Jul 05 '17 at 21:19
@JoepBeusenberg Request object is accessible via the Controller object. The Request.Properties collection allows storing arbitrary data. — Darrel Miller, Jul 06 '17 at 01:02
@DarrelMiller, that's not really the same, because that would require you to pass around the controller or the request object to other assemblies. That's exactly what we're trying to avoid with .Current. — Joep Beusenberg, Jul 17 '17 at 09:46
@JoepBeusenberg Creating separate assemblies that only work when they are called from an assembly that is executing within the context of a HTTP request of one particular web stack seems like it might make testing, maintenance and reuse a challenge. — Darrel Miller, Jul 17 '17 at 16:31
@DarrelMiller Quite the contrary. I have separated business logic from the actual web project. Using dependency injection I can add a webapi-aware library on top of the business logic. But this library breaks when the business logic has done `.ConfigureAwait(false)` somewhere down the line. There is no request or controller explicitly handed through the business layer, since that one is not web-aware. This is useful for example for a logging module that can inject the request details when the business logic writes a generic `TraceInformation`. — Joep Beusenberg, Jul 20 '17 at 11:47

score 171 · Accepted Answer · edited Feb 04 '20 at 21:41

171

Please ensure you are writing an ASP.NET 4.5 application, and targeting 4.5. async and await have undefined behavior on ASP.NET unless you are running on 4.5 and are using the new "task-friendly" synchronization context.

In particular, this means you must either:

Set httpRuntime.targetFramework to 4.5, or
In your appSettings, set aspnet:UseTaskFriendlySynchronizationContext to true.

More information is available here.

edited Feb 04 '20 at 21:41

Dan Is Fiddling By Firelight

5,981
17
77
128

answered Aug 22 '13 at 15:06

Stephen Cleary

437,863
77
675
810

I am definitely on .NET 4.5 – welegan Aug 22 '13 at 15:07
2

I just created a new ASP.NET 4.5 WebAPI project, copy/pasted your code, and did a test. It worked perfectly for me (neither exception was thrown). Please re-check that you are running on *and targeting* 4.5. – Stephen Cleary Aug 22 '13 at 15:10
3

I have Target framework: .NET Framework 4.5 set. I don't know what to tell you, it's definitely null on my local machine. – welegan Aug 22 '13 at 15:14
I did already mention it twice (the first time [with a link](http://blogs.msdn.com/b/webdev/archive/2012/11/19/all-about-httpruntime-targetframework.aspx)), but just to emphasize: you have to target 4.5 in the web.config. ASP.NET 4.5 introduced a "quirks mode" on the server side and you *have* to turn that off to get `async`/`await` working correctly. See the link for all the gory details. – Stephen Cleary Aug 22 '13 at 15:16
26

the `` is what solved it, thanks for clarifying. – welegan Aug 22 '13 at 15:16
Yes, in my [`async` on the server side talk](http://blog.stephencleary.com/2013/08/slides-available-thatconference-2013.html) I use the Picard WTF?! meme when I talk about the quirks mode on the server. :) – Stephen Cleary Aug 22 '13 at 15:18
Does not work with .NET 4.5.1? I had to downgrade to 4.5 to make the sample code in this question to work (after puting httpRuntime.targetFramework to 4.5 in Web.Config) – Vince Feb 27 '15 at 14:02
1

@Vince: 4.5.1 should work fine. I'm not sure if you should/could set `targetFramework` to 4.5.1 or 4.5, but async on 4.5.1 should work fine. – Stephen Cleary Feb 27 '15 at 15:08
1

It must be mentioned, that using ConfigureAwait(false) in action method will make HttpContext.Current = null. It's obvious but still. – Michael Logutov Jul 15 '16 at 14:22
1

What if you wrote your own managed handler? I keep coming up with HttpContext.Current=null in there even after adding these items in the web.config. – Brain2000 Oct 21 '16 at 05:38
@Brain2000: I have no experience with that, but from what I understand it *should* work. Try to reduce your code to a minimal repro and post it as a question. – Stephen Cleary Oct 21 '16 at 15:01
@StephenCleary If I find it's not easy to find, I will. You clearly know your stuff in this area! If anyone can find the answer, it would be you. – Brain2000 Oct 21 '16 at 15:18
@Stephen Cleary, the exception is thrown here due to different implementation in the frameworks i.e. >=4.5 and frameworks < 4.5 ? If so there should be a KB article from Microsoft regarding this ? – Necromancer May 07 '18 at 09:59
1

@Necromancer: A KB article wouldn't be out of the question. The information is a bit hard to find right now. OTOH, .NET 4.0 is considered quite old at this point. – Stephen Cleary May 08 '18 at 03:25
1

I have my WebAPI project set to 4.6 and some class library projects that are referenced are set to targetFramwork to 4.5 and have specified in my system.web and . I don't have .ConfigureAwait anywhere in my solution and yet HttpContext is null for me. Can someone help? @StephenCleary – Rahul Apr 22 '19 at 14:19
@Rahul: Please post a question with a minimal, reproducible example, and we'll be able to help you. – Stephen Cleary Apr 22 '19 at 14:30
@Rahul the same for me! my action is `Task` and the `HttpContext.Current` is null **before** the await function, I mean, whaat? I tried everything here... .net 4.6.1 – JobaDiniz Mar 22 '20 at 04:58
@JobaDiniz: Can you post a question with a minimal, reproducible example? – Stephen Cleary Mar 22 '20 at 23:06
Dear @StephenCleary , I know you the best in mltithreading and asynchronous topics. I want to ask you if you find it helpfull, do some clarification in my question: https://stackoverflow.com/q/61756617/9212040 thanks in advance – Arman Ebrahimpour May 14 '20 at 15:31

score 33 · Answer 2 · answered Jan 28 '14 at 18:16

As @StephenCleary correctly pointed out, you need this in your web.config:

<httpRuntime targetFramework="4.5" />

When I was first troubleshooting this, I did a solution-wide search for the above, confirmed it was present in all my web projects and quickly dismissed it as the culprit. Eventually it occurred to me to look at those search results in full context:

<!--
  For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.

  The following attributes can be set on the <httpRuntime> tag.
    <system.Web>
      <httpRuntime targetFramework="4.5" />
    </system.Web>
-->

Doh.

Lesson: If you upgrade a web project to 4.5, you still need to get that setting in place manually.

Another gotcha is this is different from – Andrew Apr 11 '14 at 00:10 — Andrew, Apr 11 '14 at 00:10

score 7 · Answer 3 · answered Jul 23 '20 at 19:54

I ran into this issue recently. As Stephen pointed out not setting explicitly the target framework can generate this issue.

In my case, our Web API was migrated to version 4.6.2 but the runtime target framework was never specified in the web config, so basically this was missing inside the <system.web> tag:

If you have doubts about the framework version you are running this may help: Add the following line on any of your Web API methods and set a breakpoint to verify what type is currently loaded at runtime and verify it is not a Legacy implementation:

You should see this (AspNetSynchronizationContext):

Instead of LegazyAspNetSynchronizationContext (Which was what I saw before adding the target framework):

If you go to the source code (https://referencesource.microsoft.com/#system.web/LegacyAspNetSynchronizationContext.cs) you will see that the Legacy implementation of this interface lacks of asynchronous support.

I spent a lot of time trying to find the source of the issue and Stephen´s response helped a lot. Hope this answer provides some more information about the issue.

Darin Dimitrov · Answer 4 · 2013-08-22T15:13:42.993

3

Is my test flawed, or is there some web.config element I'm missing here that would make HttpContext.Current resolve correctly after an await?

Your test is not flawed and HttpContext.Current should not be null after the await because in ASP.NET Web API when you await, this will ensure that the code that follows this await is passed the correct HttpContext that was present before the await.

edited Aug 22 '13 at 15:13

answered Aug 22 '13 at 14:58

Darin Dimitrov

1,023,142
271
3,287
2,928

Are you sure about the same continuation thread for WebAPI? I dealt with the [case](http://stackoverflow.com/q/18284998/1768303) where it was a different thread. – noseratio Aug 22 '13 at 15:06
5

ASP.NET will resume on any thread pool thread, but with the correct request context. – Stephen Cleary Aug 22 '13 at 15:06
2

Yes, you are right, the thread might not be the same but HttpContext.Current will be the same as before the await. I have updated my question. – Darin Dimitrov Aug 22 '13 at 15:14
4

HttpContext.Current is null after an await in my code, and I'm targetting .net 4.6.1. – Triynko Jun 25 '18 at 22:31
Same problem here still. 4.6.1 – brianc Mar 28 '19 at 20:04
1

for me HttpContext.Current is null **before** an await function – JobaDiniz Mar 22 '20 at 04:51
Me too HttpContext.Current is gone 4.8 – realPro May 03 '20 at 23:40

Mark C. · Answer 5 · 2021-04-14T18:41:19.713

I wanted to comment and say that the previous answers hit the nail on the head from a web.config perspective, however, there can be inherited settings from IIS that can override this functionality if you simply use <httpRuntime targetFramework="4.5" />.

What I mean: The true fix here is this setting: <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />

If you don't explicitly include this setting but rely on <httpRuntime targetFramework="4.5" /> to configure this setting - it will be overridden by any settings in IIS.

If you are debugging or logging the type of SynchronizationContext and you find out it's of type Legacy, you may want to check for a setting at the IIS or hosting Site level.

Will yield LegacyAspNetSynchronizationContext:

Web.config:

    <add key="webpages:Version" value="3.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
    <add key="aspnet:UseLegacyEncryption" value="true" />
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.8" />
    <httpRuntime targetFramework="4.5" />
  </system.web>

Will yield AspNetSynchronizationContext (this is what you want):

    <add key="webpages:Version" value="3.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true"/>
    <add key="aspnet:UseLegacyEncryption" value="true" />
    <add key="aspnet:UseLegacyMachineKeyEncryption" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.8" />
    <httpRuntime targetFramework="4.5" />
  </system.web>

*Note there is no override setting in IIS here

tvb2754 · Answer 6 · 2021-09-12T16:26:29.790

I tried all the other answers here and HttpContext.Current was still null.

.net Framework 4.6.1 / MVC

I'm using HttpContext.Current to get the mapped path for an upload to App_Data

This is how I fixed the issue:

I just obtain the current HttpContext.Current in a variable and then reset it after my await calls.

var tempHttpContextCurrent = System.Web.HttpContext.Current;

var report = await reportingUtilities.GetReport(reportId, currentUserRubixId).ConfigureAwait(false);

// reset the HttpContext.Current after the await call.
System.Web.HttpContext.Current = tempHttpContextCurrent;

score 0 · Answer 7 · answered May 12 '22 at 03:13

In my case the problem was I forget await in the begining of stack, explicity in my constructor action method

NOTE: Using net core 5.0 with IHttpContextAccessor

So the problem was in code...

[HttpPost]
public async Task AnyAction()
{
    await service.MethodReturningTask(); //await was not
}

Why is HttpContext.Current null after await?

7 Answers7

Will yield LegacyAspNetSynchronizationContext:

Will yield AspNetSynchronizationContext (this is what you want):

Linked