Skip to content
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

Add more info to UnrecognizedMediaType #43100

Merged
merged 8 commits into from
Aug 10, 2022
Merged

Add more info to UnrecognizedMediaType #43100

merged 8 commits into from
Aug 10, 2022

Conversation

wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented Aug 4, 2022

This only ever gets fired for the request body, not the response body.

@wtgodbe wtgodbe requested a review from halter73 August 4, 2022 19:53
@ghost ghost added the area-runtime label Aug 4, 2022
@@ -29,6 +29,9 @@ internal static partial class HttpLoggingExtensions
[LoggerMessage(5, LogLevel.Debug, "Decode failure while converting body.", EventName = "DecodeFailure")]
public static partial void DecodeFailure(this ILogger logger, Exception ex);

[LoggerMessage(6, LogLevel.Debug, "Unrecognized Content-Type for body.", EventName = "UnrecognizedMediaType")]
public static partial void UnrecognizedMediaType(this ILogger logger);
[LoggerMessage(6, LogLevel.Debug, "Unrecognized Content-Type for request body.", EventName = "RequestUnrecognizedMediaType")]
Copy link
Member

Choose a reason for hiding this comment

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

Let's keep the same id for both logs to avoid any possible breakage no matter how unlikely. We should be able to parameterize just the request/response part of the message.

I was going to suggest including what the unrecognized content-type was exactly. It seems useful for debugging, but then I realize most people logging the body are probably logging the header separately anyway.

Copy link
Member

Choose a reason for hiding this comment

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

I was going to suggest including what the unrecognized content-type was exactly.

Should there be a different log when there isn't a media type header?

Copy link
Member Author

Choose a reason for hiding this comment

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

Is that a common scenario?

Copy link
Member

Choose a reason for hiding this comment

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

Probably? Isn't that what the original issue was sort of about?

Copy link
Member

Choose a reason for hiding this comment

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

Agreed. An "Unrecognized Content-Type" log when there isn't a "Content-Type" to begin with is super confusing. I would not log anything at all in that case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added a new log message & a test

@Tratcher
Copy link
Member

Tratcher commented Aug 9, 2022

Is there an issue or other feedback about this?

@BrennanConroy
Copy link
Member

Is there an issue or other feedback about this?

#43100 (comment)

@wtgodbe wtgodbe merged commit 2f29a5e into main Aug 10, 2022
@wtgodbe wtgodbe deleted the wtgodbe/mediaType branch August 10, 2022 17:02
@ghost ghost added this to the 7.0-rc1 milestone Aug 10, 2022
@amcasey amcasey added area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlesware and removed area-runtime labels Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlesware
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants