Log bytes for HTTP/1.1 parsing failures

[Tratcher]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

HTTP/1.1 request formats are not well standardized and clients often bend/break the spec. This can cause Kestrel to reject the request with a 4XX. When this happens, it can be hard for the app to understand exactly what was wrong with the request.

Describe the solution you'd like

When a parsing failure is encountered, we should report the raw bytes from the request buffer. This will bypass the common debugging step of "please capture a network trace" and is even better than a network trace because it can capture the decrypted content when using TLS.

Additional context

Where should this be reported? In the BadRequest event?

[adityamandaleeka]

Triage: we need to figure out the shape of this that will allow it to get backported to 6 if that's what we want.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Tratcher]

We do have some of this already:

aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http/HttpParser.cs

Lines 530 to 534 in bcf7319

	throw GetInvalidRequestException(
	IsTlsHandshake(requestLine) ?
	RequestRejectionReason.TlsOverHttpError :
	RequestRejectionReason.InvalidRequestLine,
	requestLine);

aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http/HttpParser.cs

Lines 549 to 551 in bcf7319

	_showErrorDetails
	? headerLine.GetAsciiStringEscaped(Constants.MaxExceptionDetailSize)
	: string.Empty);

Note _showErrorDetails is set based on the log level.

aspnetcore/src/Servers/Kestrel/Core/src/Internal/KestrelServerImpl.cs

Line 120 in bcf7319

HttpParser = new HttpParser<Http1ParsingHandler>(trace.IsEnabled(LogLevel.Information), serverOptions.DisableHttp1LineFeedTerminators),

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.