Skip to content

Remove workaround in HeaderPropagationMiddleware #20533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 9, 2020
Merged

Remove workaround in HeaderPropagationMiddleware #20533

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions src/Middleware/HeaderPropagation/src/HeaderPropagationMiddleware.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,8 +33,7 @@ public HeaderPropagationMiddleware(RequestDelegate next, IOptions<HeaderPropagat
_values = values ?? throw new ArgumentNullException(nameof(values));
}

// This needs to be async as otherwise the AsyncLocal could bleed across requests, see https://github.com/aspnet/AspNetCore/issues/13991.
public async Task Invoke(HttpContext context)
public Task Invoke(HttpContext context)
{
// We need to intialize the headers because the message handler will use this to detect misconfiguration.
var headers = _values.Headers ??= new Dictionary<string, StringValues>(StringComparer.OrdinalIgnoreCase);
Expand All @@ -57,7 +56,7 @@ public async Task Invoke(HttpContext context)
}
}

await _next.Invoke(context);
return _next.Invoke(context);
}

private static StringValues GetValue(HttpContext context, HeaderPropagationEntry entry)
Expand Down
38 changes: 0 additions & 38 deletions src/Middleware/HeaderPropagation/test/HeaderPropagationMiddlewareTest.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -185,43 +185,5 @@ public async Task MultipleEntries_AddsFirstToProduceValue()
Assert.Contains("in", CapturedHeaders.Keys);
Assert.Equal("Test", CapturedHeaders["in"]);
}

[Fact]
public async Task HeaderInRequest_WithBleedAsyncLocal_HasCorrectValue()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed these tests because it's the responsibility of the server, not the middleware, to ensure it has a fresh ExecutionContext for each request. The HeaderPropagationMiddleware does not have any functional tests, and @benaadams already added functional tests to verify IAsyncLocals in general work as expected with Kestrel.

That said, I did manually verify that #14146 fixes things so that the HeaderPropagationMiddleware sees a fresh HeaderPropagationValues each request after removing async from Invoke. And verified this was not the case without the changes from #14146.

{
// Arrange
Configuration.Headers.Add("in");

// Process first request
Context.Request.Headers.Add("in", "dirty");
await Middleware.Invoke(Context);

// Process second request
Context = new DefaultHttpContext();
Context.Request.Headers.Add("in", "test");
await Middleware.Invoke(Context);

// Assert
Assert.Contains("in", CapturedHeaders.Keys);
Assert.Equal(new[] { "test" }, CapturedHeaders["in"]);
}

[Fact]
public async Task NoHeaderInRequest_WithBleedAsyncLocal_DoesNotHaveIt()
{
// Arrange
Configuration.Headers.Add("in");

// Process first request
Context.Request.Headers.Add("in", "dirty");
await Middleware.Invoke(Context);

// Process second request
Context = new DefaultHttpContext();
await Middleware.Invoke(Context);

// Assert
Assert.Empty(CapturedHeaders);
}
}
}