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

Future of Problem Details Middleware #177

Open
pinkfloydx33 opened this issue Jun 28, 2022 · 2 comments
Open

Future of Problem Details Middleware #177

pinkfloydx33 opened this issue Jun 28, 2022 · 2 comments

Comments

@pinkfloydx33
Copy link

With the proposed problem details changes in aspnetcore 7.0, does this effectively kill your library? Or do you still see usages of it? Personally I think the exception mapping alone is a reason to stick with this library and I'm not sure the proposed API shape covers those cases (at least as easily as here)

I ask mainly because the current proposed API includes extension methods for IServiceCollection that look like they are going to conflict with the ones this library offers. Any of us that wish to stick with your version would need to fully qualify the extension class name since we'd already be likely to have Microsoft.Extensions.DependencyInjection namespace already imported.

If you think there's still going to be a valid use case for this library, might I suggest offering an additional set of overloads of AddProblemDetails with a slightly different name?

@brunolins16
Copy link

Personally I think the exception mapping alone is a reason to stick with this library and I'm not sure the proposed API shape covers those cases (at least as easily as here)

@pinkfloydx33 can you share what are the most useful mapping options that you are using? As I mentioned in the original proposal, I would like to have a follow up issue for the Exception Handler middleware

If you think there's still going to be a valid use case for this library, might I suggest offering an additional set of overloads of AddProblemDetails with a slightly different name?

The proposed public API does not add anything other than services that can be used by other parts of the framework (eg.: Middleware or filters), of course the implementation will update some of those middleware to use it, if that will cause a lot of confusion/conflict, we can easily accept a different name there, if we find one :)

@dnperfors
Copy link

As it turns out, there are also two middleware classes provided: UseExceptionHandler() and UseStatusCodePages() which will make sure the result is in the ProblemDetails format. I only just tried it out quickly, so I am not sure if it completely can replace this middleware, but it looks promising.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants