I'm learning about using problem details middleware found here
I have the setup working all fine but I got curious why it's mapping validation errors differently than the default status code.
To explain better, in the sample repo provided by the owner try the following:
call https://localhost:54547/mvc/modelstate
response "status":422
In the project's Program.cs, comment out the MVC override AddProblemDetailsConventions (line 46) and call again
response "status":400
400 is the default status code for validation errors automatically inserted when you add the ApiController attribute to your controller.
In a previous discussion with the owner here, it was recommended to call AddProblemDetailsConventions
if you want to have 100% consistent error responses from your API (produced by the middleware).
I understand the middleware is to control the "format" of response error message to follow RFC7870, but why is it changing the error code for this example case? is 422 more specific/better practice than 400?
I tried to look for more details, but couldn't find any. like what other mappings are changed, or if there's a way to configure the middleware mapping for default validation error (since in our project we already have test suit asserting on 400 for validation scenarios).
From that same conversation with the author you cited, he does mention a way to override the default status response code in this post.
Regarding the 422 status code; it's an opinion of mine that syntactically correct, but semantically invalid requests should return back a different status code than 400 Bad Request
He also mentions that not everyone may choose to follow that convention, so he provides a way to override the default:
Some people don't like it (often because it's part of the WebDAV RFC and not an "official" HTTP RFC (but this will soon change, with the inclusion of 422 in HTTPbis' upcoming HTTP Semantics RFC, which obsoletes RFC 7231), so I've added an option to change it:
And provides a link to the source code value of ProblemDetailsOptions.ValidationProblemStatusCode.
You can pass in the options value to the configuration like this to change the default back to a 400 status code:
services.AddProblemDetails(options =>
{
options.ValidationProblemStatusCode = 400;
});
Or if you prefer to use the private configuration method like in the sample library:
private void ConfigureProblemDetails(ProblemDetailsOptions options)
{
options.ValidationProblemStatusCode = 400;
// the rest of the code setup he used in the example
}
As far as the other mappings that were changed, I don't see much in the source code that is configured by default apart from setting the status code to 500 if there is no status code present.
I have the following situation:
ASP.NET Core 2 serving api requests on /api/*
ASP.NET Core 2 serving health requests on /health
ASP.NET Core 2 servering proxy requests on /svc/*
ASP.NET Core 2 serving SPA on /app OR / (if you go to example.com it will serve files from /app/ folder.
Now, if someone requests an entity which does not exist, an exception is thrown. This is handled by using the following in Startup.cs
app.UseExceptionHandler("/error");
The ErrorController handles these exceptions and return's stuff like NotFound(), BadRequest(), etc. In the end, they are all JSON responses.
Now, if you were to go to the /hshfdhfgh url, this now results in an empty 404 page because nothing matches. But what I would like to do is to be able to add some custom HTML views for error pages. Perhaps with Razor Pages or something.
I have looked this up and you need it is advised to use the UseExceptionHandler("/error") method so you can return some views. But this would conflict with my JSON responses!
The only thing I can come up with is something like:
if request does not start with /health, /svc/, /, /app or /api/
app.UseExceptionHandler("/error/404");
else
app.UseExceptionHandler("/error");
But this feels very hacky. Is there any other way?
And, what would be the best/easiest way to add razor support to my project? currently it has none.
You can use this as a start (it's netcore 3.1, but I don't think we had to make significant changes when migrating from 2). It feels hacky and it's pain to get the handler itself right, and to put it at the exactly right place in Startup (especially if you combine it with things like dealing properly with Unauthorized responses, razor views and static files for those razor views). But I didn't find a better way.
public static readonly PathString ApiPath = new PathString("/api");
public static readonly PathString StaticFilePath = new PathString("/site");
static bool IsApiRequestPredicate(HttpContext context) => context.Request.Path.StartsWithSegments(ApiPath, StringComparison.InvariantCulture);
static bool IsStaticFilePredicate(HttpContext context) => context.Request.Path.StartsWithSegments(StaticFilePath, StringComparison.InvariantCulture);
...
app.UseWhen(x => !IsApiRequestPredicate(x) && !IsStaticFilePredicate(x), builder =>
{
builder.UseStatusCodePagesWithReExecute("/Error/StatusCodeViewReexecuteHandler/{0}");
app.UseDeveloperExceptionPage();
});
app.UseWhen(x => IsApiRequestPredicate(x), builder =>
{
builder.UseExceptionHandler("/Error/ExceptionApiReexecuteHandler");
builder.UseStatusCodePagesWithReExecute("/Error/StatusCodeApiReexecuteHandler/{0}");
});
You could also use only one handler and decide based on OriginalPath in ErrorController action:
var errorFeature = HttpContext.Features.Get<IStatusCodeReExecuteFeature>();
var exceptionFeature = HttpContext.Features.Get<IExceptionHandlerFeature>();
if (errorFeature.OriginalPath.StartsWith("/api", StringComparison.InvariantCulture))
{
return BadRequest(new { error = "entity not found" });
} else {
return View("NotFound");
}
// exceptionFeature gives you access to the exception thrown
I need to figure out from a middleware if a route or context points to a valid endpoint in my API. I want to do this in order to send a valid json-formatted error response, instead of the default empty error message that the API sends.
An alternative solution that figures out that the endpoint resulted in nothing is fine too. My first thought was to use a middleware, but perhaps sending an error with a fall-back controller works too?
I would like to give an answer to my own question, as I have found a way to manually check if a route exists. This was something I did not think of at the time, as I did not realise you could get information about your API through a dependency.
The way I have done this now is to make use of the IActionDescriptorCollectionProvider provider. This will allow me to receive all current routes in the API. Using this, I created the following middleware:
public async Task InvokeAsync(HttpContext context)
{
var path = context.Request.Path.Value;
var routes = _actionDescriptorCollectionProvider.ActionDescriptors.Items.Select(ad => $"/{ad.AttributeRouteInfo.Template}").ToList();
if (!routes.Any(route => path.Equals(route, StringComparison.InvariantCultureIgnoreCase))) {
context = await context.HandleRequest(HttpStatusCode.NotFound, "RouteNotFound", "De server heeft geen geldige actie voor de gegeven route.");
return;
}
await _next(context);
}
This fully allows me to respond with a custom error (this is using HandleRequest(), which is an extension of my own), and handle the rest in the frontend.
I found another way to solve this to use pre-initialised documentation by the API. I'm not sure what to call it, but adding the following code to your csproj file creates an XML which gives the same benefits:
<NoWarn>$(NoWarn);1591</NoWarn>
<DocumentationFile>Files\Documentation\$(Configuration)_$(AssemblyName)_doc.xml</DocumentationFile>
This means that the XML has be parsed of course.
I am still looking for different solutions, perhaps better ones if there are problems with this one.
I upgraded my project to Core 3.0 from 2.2 and everything seems to work well, except one get JSON request. I have the following Js code doing an Ajax request to the Home controller:
var isLastPage = false;
var incidentModel = {
incidents: ko.observableArray([]),
getIncidents: function(a) {
var self = this;
//var $incdiv = $('#incidentsList');
$.getJSON('#Url.Action("AjaxPageAsync", "Home")', { page: page++, user: user, type: type }, function(data) {
//console.log(data);
self.incidents(self.incidents().concat(data));
if (data[0].IsLastPage) {
isLastPage = true;
}
a();
});
}
}
The Home controller is like this:
public async Task<ActionResult> AjaxPageAsync([FromQuery] string type, [FromQuery] string user, [FromQuery] int? page)
{
//Get some json data
return Json(Incident);
}
As you may tell, I'm using knockout (version 3.5.0 & jquery 3.3.0) which both are working fine on other pages. However, the getJSON request in the js code above is returning a 404:
GET https://localhost:44366/Home/AjaxPageAsync?page=1&user=&type=&_=1575386778917 404
The debug output looks similar:
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/2.0 GET https://localhost:44366/Home/AjaxPageAsync?page=1&user=&type=&_=1575386536876
The 2.2 version is identical and works fine. I thought it might be the number appended onto the end of the url, but that exists in 2.2 as well.
At this point, I'm thinking it's a problem with the syntax of my AjaxPageAsync task in the controller, but not sure what it should be.
Anyone know where I'm going wrong here? Thank you.
According to https://github.com/aspnet/AspNetCore/issues/8998, in .NET Core 3.0 Async is trimmed from Action name. Your endpoint is available at /Home/AjaxPage. You can change this behaviour by replacing
services.AddControllers();
with
services.AddControllers(options => options.SuppressAsyncSuffixInActionNames = false);
in ConfigureServices method, or just use the new routes
I would start with an elimination of getJson and what not, run a manual Postman or Curl against the endpoint to create the simplest reproducible use case to troubleshoot.
If it's still 404, you know its the configuration side of AspNetCore.
If it's not 404, you have a problem specific with an Ajax call to NetCore 3.0. That can narrow the scope of what you are searching for (and thereby your Google parameters).
My guess to the actual problem is the routing you have setup is not working or configuration has shifted in NetCore3. This usually happens when you had a routing setup in NetCore 1.0/1.2, years later migrated an example to NetCore 2.0 which was backwards compatible, years later again, bumped to NetCore 3.0, and NetCore 3 may not exactly support that routing configuration without some additional hoops to jump through.
Try creating a simple helloworld in the same controller and wiring it up. If that works you have essentially isolated the issues to the controller/method and the routing.
If didn't support it at all, it wouldn't compile though...
...so swings and roundabouts!
Also, it's Task but you are only returning Result... this is probably a simplified example but make sure you are returning/awaiting correctly.
Looking at specifically Async method tags with AspNetCore3 and there is an MvcOption that SuppressesAsyncSuffixActionName and is true by default in AspNetCore 3.0 (looks like Piotr found it first!)
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.mvcoptions.suppressasyncsuffixinactionnames?view=aspnetcore-3.0
Trying to setup swagger in conjunction with a web application hosted on IIS express. API is built using ASP Net Core. I have followed the instructions prescribed on the relevant microsoft help page regarding Swashbuckle and ASP.NET Core.
Thus far I have got the swagger page to load up and can see that the SwaggerDoc that I have defined is loading, however no API's are present. Currently am getting the following error:
"Fetch error undefined ./swagger/v1/swagger.json"
public class Startup
{
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// services.AddDbContext<TodoContext>(opt =>
// opt.UseInMemoryDatabase("TodoList"));
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
// Register the Swagger generator, defining 1 or more Swagger documents
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new Info { Title = "API WSVAP (WebSmartView)", Version = "v1" });
});
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
// Enable middleware to serve generated Swagger as a JSON endpoint.
app.UseSwagger();
// Enable middleware to serve swagger-ui (HTML, JS, CSS, etc.),
// specifying the Swagger JSON endpoint.
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("./swagger/v1/swagger.json", "My API V1");
c.RoutePrefix = string.Empty;
});
app.UseMvc();
}
}
So after a lot of troubleshooting it came down to basically two things, but I feel that in general this could be helpful to someone else in the future so I'm posting an answer.
First- if ever your stuck with the aforementioned error the best way to actually see whats going on is by adding the following line to your Configure() method
app.UseDeveloperExceptionPage();
Now if you navigate to the 'swagger/v1/swagger.json' page you should see some more information which will point you in useful direction.
Second- now for me the error was something along the lines of
'Multiple operations with path 'some_path' and method 'GET' '
However these API were located inside of dependency libraries so I was unable to apply a solution at the point of definition. As a workaround I found that adding the following line to your ConfigureServices() method resolved the issue
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new Info { Title = "API WSVAP (WebSmartView)", Version = "v1" });
c.ResolveConflictingActions(apiDescriptions => apiDescriptions.First()); //This line
});
Finally- After all that I was able to generate a JSON file but still I wasn't able to pull up the UI. In order to get this working I had to alter the end point in Configure()
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("./v1/swagger.json", "My API V1"); //originally "./swagger/v1/swagger.json"
});
I'm not sure why this was necessary, although it may be worth noting the web application's virtual directory is hosted on IIS which might be having an effect.
NOTE: Navigating to swagger/v1/swagger.json will give you more details, for me it was causing issue due to undecorated action. This information is mentioned in comment by #MarkD
I've been working with .Net Core 3.1 and I spent some time to find out and understanding what was going on.
The issue can arise from many different reasons:
Swagger configuration errors
Classes with the same name but in different namespaces
Public methods without the rest attribute (Get, Post, etc.)
First, take a look the link below just to check if your setup is ok:
Add Swagger(OpenAPI) API Documentation in ASP.NET Core 3.1
Then,
A good tip to find out the problem is to run the application without to use IISExpress and check the console log. Any error found to generate the documentation will be displayed there.
In my case, the problems was that I had a public method (that should be private) without any rest attribute:
After change the method from public to private I solve the issue.
I was able to find the error by opening the network tab and looking at the response for swagger.json
Simply navigate to https://localhost:{PortNo}/swagger/v1/swagger.json and get much more details about the error message.
also I had similar problem in .NET 5.0, I solved below way:
I added this line as attribute over controller:
[Consumes("application/json")]
I've been working with .NET 5 and I spent some time trying to understand what was going on.
I got an error like the one below:
Then I resolved this problem by the following:
Open startup.cs file
Add the following code in Configure method
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseSwagger(c =>
{
c.RouteTemplate = "/swagger/{documentName}/swagger.json";
});
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "API v1"));
}
And in ConfigureServices method
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "API", Version = "v1" });
c.ResolveConflictingActions(apiDescriptions => apiDescriptions.First());
});
Thanks to TheCodeBuzz for Resolved: Failed to load API definition (undefined /swagger/v1/swagger.json)
Note the difference between the RouteTemplate string and the SwaggerEndpoint string. One uses {documentName} and the other uses "v1" as a literal.
I've come across the same error before, after struggling to find the reason, I discovered that one of my API in one of my controllers have no HTTP verb as an attribute, So I fixed it by putting [HttpGet] on my API.
So here is my advice, check your API controllers, maybe you forget the same thing as me!
Take a look at my code, I realized that I should change this :
public async Task<Product> ProductDetail(int id)
{
return await _productQueries.GetProductDetail(id);
}
to this:
[Route("ProductDetail")]
[HttpPost]
public async Task<Product> ProductDetail(int id)
{
return await _productQueries.GetProductDetail(id);
}
I had similar issue, I solved it using the Route attribute on the offending controller method:
[HttpGet, Route("Throw")]
public ActionResult<string> Throw()
{
_logger.LogInformation("I think I am going to throw up");
throw new NotSupportedException("For testing unhandled exception logging.");
}
I felt that ResolveConflictingActions may potentially sweep a real issue under the rug.
I had two issues that caused the same error.
I have two classes with the same name under two different namespaces. Swagger could not reconcile this when generating the swagger doc. To fix it I added the line options.CustomSchemaIds(x => x.FullName);
See explanation here
I had a method without an [HttpGet] annotation. Swagger needs the HTTP endpoints to be explicitly defined.
I found both issues by inspecting the Output in visual studio after the API loaded.
I just spent two hours on this issue, but my cause was entirely different, it had NOTHING to do with routes or annotations. I had 2 classes with the same name (but different namespaces): MyProject.Common.ClassName and MyProject.Api.ClassName. Swagger/swashbuckle couldn't tell the difference between the two, so I got that useless error.
Those 2 hours were spent trial-and-error commenting out controllers and endpoints, to finally find 3 endpoints offending endpoints. All 3 endpoints had different routes, different (or no) custom authorization, and different method names. It turned out that all 3 endpoints either accepted a parameter, or returned an object, that contained the API version of my class. Nowhere was the Common version used. Swagger couldn't tell them apart, and puked all over itself.
Why oh why can't Swagger or Swashbuckle provide actual error messages? Would have saved me a couple of hours...
I just forgot to add HTTP attributes in my controller as soon as I add HTTP attribute it works like a charm for me.
Source : https://www.benday.com/2020/12/16/webapi-core-swagger-failed-to-load-api-definition-error/
Here we go:
I created WEB Controller instead of WEB API Controller. That makes this kind of error.
During creation of new Controller, make sure that you created right WEB API controller.
Surely it is one of the Controller's method that is faulty. To get the method, at times you might need to take out all your controllers, Try and insert them one after the other then you will test along to find the Controller with bugs.
For ex. If you have like 3Controllers say
>Controller
>>>AuthController
>>>UserController
>>>HomeController
Take two out of the controllers out and test the controller by adding one controller after each successful testing. With that you will know the controller that has a faulty method.
>Controller
>>>AuthController
If the methods in AuthenController is fine, It will run, If not Check the methods.
>Controller
>>>AuthController
>>>UserController
and carry out the next check on the controller like that of Authen.
I had the same problem, so I checked it using inspect element on the browser. The "Console" tab shows the file where the problem originated from (v1/swagger/json:1). Opening it by clicking it showed that one of the helper methods I used in my controller was "Public". Changing it to "Private" fixed the problem for me.
This page also has good tips:
https://btrehberi.com/swagger-failed-to-load-api-definition-fetch-error-undefined-hatasi-cozumu/yazilim/
Swagger in my case needed [HttpAction] with all public members in controller. Unfortunately I misspelled constructor name and since it was public, was throwing this error.
For ASP.NET Core 3.1 I had to ensure the verb were not ambiguous and I found this out by first running the API project without IIS in VS2019 (Green Arrow > left-click the carrot icon and select the name of the project this causes a console window to appear on start up so you can inspect what's happening and see errors).
[HttpGet("MyEndPointA")
Then Swagger is able to generate the documentation correctly.
Solved issue in dotNet 6! Just change the attribute order of [ApiController]
In my case, there were 2 methods in the Controller class, which had the same annotations, and URL. (Our team was using Entity Framework, ASP.NET and Swagger.)
[HttpGet("GetMyGreatData/{patientId}")]
[ValidatePatient]
public async Task<ActionResult<ServiceResponse<IEnumerable<MyGreatModel>>>> GetMyGreatData(
[FromRoute] int patientId, int offset = 0, int limit = 0)
{
//method details...
}
[HttpGet("GetMyGreatData/{patientId}")]
[ValidatePatient]
public async Task<ActionResult<ServiceResponse<IEnumerable<MyGreatModel>>>> GetMyGreatData(
[FromRoute] int patientId,
[FromQuery] DateTimeOffset? startdate = null,
[FromQuery] DateTimeOffset? endDate = null,
int offset = 0,
int limit = 0)
{
//method details...
}
deleting one method solved the issue for me.
I was having the same issue, the base controller was not decorated with Http and removing that has made it work.
This error can happen when you deploy an App Service to Azure. I've redeployed the App Service to Azure and the error disappeared.
When this happened to me, I tracked it down to URL path param having an underscore which it's compatible with the asp generator
Changing this:
/block-content/{machine_name}:
To this
/block-content/{machineName}:
Solved it for me
<b>make sure the name "v1" matches the path in the swagger endpoint</b>
<p>
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo {
Title = "ODAAPP",
Version = "v1" });
});
</p>
<br/>
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
"ODAAPP v1"));
enter code here
This will also happen if you use same route for multiple action methods (Overloading is OK)
In my case, the project was configured to authenticate using identity server 4 using AddPolicy() at startup.cs and there were usages of [Authorize]
I removed the things for startup.cs and usages of [Authorize]
Will update more soon
In my case I had two identicall inner classes.
Extracted them to a single one refactored the namespaces and voilá, all returned to work properly.
I have experienced the same error when I was using Swagger and also Microsoft.AspNetCore.OData. I usually try to use the latest version - but bringing it down to v 7.5.12 - did solve my issue.
Also adding following to every Action method in the Controller, makes it work with OData v8.x too: [HttpGet], [HttpPost], or [ApiExplorerSettings(IgnoreApi = true)]
I had a similar Fetch error 404 swagger/v1/swagger.json, when trying to integrate Swagger documentation in ASP.NET Core 3.1 Web API project. I tried almost all of the above suggestions but failed.
After an hour of hit-and-trial, I decided to give NSwag a try using this reference, instead of Swashbuckle and it just worked like a charm :)
I got the similar issues - the root cause is I forgot to add the annotations :-(
Reasons for this Error
i resolved this issue by this way
Use [HttpGet] attribute above the api controller method.
And, because of different versions of swashbuckle, these errors may come.
you should use the correct swagger endpoint url
v1/swagger.json or swagger/v1/swagger.json
choose above one based on the version you are using.
Note:
Use this url for reference https://myget.org/feed/domaindrivendev/package/nuget/Swashbuckle.AspNetCore.Swagger/6.2.3-preview-1963
Refer the official swagger documentation.
lot of information is there with crystal clear documents
https://swagger.io/docs/
'Multiple operations with path 'some_path' and method 'GET' '
[HttpGet]
public IActionResult Get()
{
return Ok(_userService.Get());
}
[HttpGet]
public IActionResult Get(int Id)
{
return Ok(_userService.Get(Id));
}
Just modify DataAnnotation:
[HttpGet]
public IActionResult Get()
{
return Ok(_userService.Get());
}
[HttpGet("{Id}"] //HERE
public IActionResult Get(int Id)
{
return Ok(_userService.Get(Id));
}