-
Notifications
You must be signed in to change notification settings - Fork 10.3k
ASP.NET Core 9 sends response content for HTTP HEAD requests #59691
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.
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
Comments
Could you test with |
With
So your guess looks likely! |
Could you tell us how you found this issue? Was it in a real-world scenario and does it have more side-effects than additional bandwidth for HEAD responses? |
It wasn't a real-world scenario, it was caught by integration tests. The HTTP client used by the tests would reuse the connection after the HEAD request (unlike most clients which would close the connection after noticing the extra data), and try to process the response content as a second response |
I've also noticed this as it brakes other tools that don't expect this behavior:
Both only happen on HEAD requests that return an |
How common is it to do a HEAD request with these tools? |
@BrennanConroy We just happen to use HEAD requests extensively in the product we're building. Vite relays requests when running the frontend locally and Postman performs the same requests for debugging. |
Until the fix is available (in ASP.NET 10?), presumably we can work-around the issue by swapping out the response body for HEAD requests for a null stream? e.g. based on some quick local testing, adding this early in the middleware pipeline appears to resolve the issue: app.Use((ctx, next) =>
{
if (HttpMethods.IsHead(ctx.Request.Method))
{
ctx.Response.Body = Stream.Null;
}
return next();
}); |
Is there an existing issue for this?
Describe the bug
In .NET 8 (and I think earlier versions), returning an
IResult
that writes a response body would not actually write the body in response to HTTP HEAD requests, but this has changed in .NET 9. I couldn't find anything in the published change notes indicating that this is an intended change.For example, with the program:
When running with .NET 8:
The second invocation uses
-X HEAD
to make curl ignore all HTTP semantics regarding the HEAD method, and so times out waiting for a response body that never arrives (hence curl's big warning!)But when running with .NET 9:
Note that the second invocation now succeeds, because the server included the response content. This violates RFC 9110 9.3.2.:
The HEAD method is identical to GET except that the server MUST NOT send content in the response.
Expected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
9.0.101
Anything else?
No response
The text was updated successfully, but these errors were encountered: