Trying to provide more info and not sure how much is relevant.
One of our webapi is deployed to IIS : abcdomain.com/xyzweb. We started upgrading our env to .net 7 from .net 5. Web api also uses ServiceStack 6.4.
One of the route defined in the c# Webapi, ServiceStack plugin is "/api". Until recently requests to endpoint abcdomain.com/xyzweb/api was fine. But now (.net 7 upgrade?) we noticed that the calls to endpoint does not reach the (http get/post method) handler. We have a small middleware defined in startup.cs configure method and see the execution flow through the middleware code when the abcdomain.com/xyzweb/api request is made and the middleware ends by calling next() and after which execution flow lost (webapi is still live).
After much trials, something I read but could not put my fingers on the content, went ahead and changed the route definition to "/apihello" instead of "/api" and then the requests started working as before.
Any pointers what made it break or what made it work?
Searching is difficult with "api", brings only irrelevant results.
I would like to add that before changing /api to /apihello, the http request would return HTTP status 200 (though it did not go to the handler) and Raw response "Error: System.NotImplementedException: The operation '' does not exist for this service".
You can disable (or change) ServiceStack's JSON /api pre-defined route with:
ConfigurePlugin<PredefinedRoutesFeature>(feature => feature.JsonApiRoute = null);
Related
I have a React frontend connecting to a .NET CORE WebAPI, I'm able to call, GET, Delete, and Create in one controller with no issues, however, on another controller, when I call the Create I get the CORS policy error message. What would cause the error in one controller and only the Create? I can call the Get and Delete with no issues, I can also call the Create from PostMan with no issues, just when I call it from my React App.
Create Code: (this works when I test it from Postman, I'm connecting to the API on my Local host for the time being, and only this one controller in the WebAPI is kicking me out the CORS policy error and only on the Create Call)
public IActionResult Create(CarDetails, details)
{
db.CarDetails.Add(details);
db.SaveChanges();
return Ok(details.DetailsId);
}
PostMan ignores CORS headers and will just not care about them. That is a reason for PostMan working while the browser does care.
With that said I do no really know why your API stops one request and not the other. Are there differences in the headers?
I think your problem would have a higher chance of getting solved when asked in a .NET forum. CORS errors are caused by settings for your backend/api host and not caused by React/JS/Client side code.
You might need to allow more headers, open up localhost:3000 or some other setting.
I got it working. once I added this to my API call file, it worked:
headers: {
"Content-type": "application/json"
}
Using Azure Functions .Net 5 and the Microsoft.Azure.Functions.Worker.Http SDK, what is the expected behaviour of HttpRequestData.Body property when the request has no body? Is it null, is it a Stream.Empty, something else?
The documentation is unhelpful, as it simply says: "A Stream containing the HTTP body data."
Azure Functions Core 5 were released this year, there is little information available.
There is information on how to read body requests with ASP Core 3 but this is not .NET 5, and I am not sure Azure Functions are expected to behave in the same way as ASP.
I was so far unable to attach the debugger to the published Function Host, which complicates diagnostics.
what is the expected behaviour of HttpRequestData.Body property when the request has no body?
The raw HTTP request body as a bytestring. This is useful for processing data in different ways like loading the data, parsing etc.
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers.
If content-length is nothing, then the request read return nothing to read. Sometimes throws errors if the EOF (Function) return type is not valid.
To read http request body from asp.net core 5 using azure functions
Create Asp.Net Core 5 Project and Azure Functions isolated environment
Add each of their references in packages/dependencies.
You need to change the target framework of Microsoft SDK version from 3.1 to 5 because by default it is create in 3.1 in Azure Functions csproj.
And We need to do changes in the local.setting.json file as well as Program.cs file in Core project for reading the Http Request Body. Refer this and this for step by step process!
In HttpRequestBody, Content-length : some numeric value (but not zero) specifies the end of the HttpRequest and its length.
If Content-Length: 0, then HttpRequestData contains empty body like { }.
if neither ("Content-Length" / "Transfer-Encoding: chunked") are present, "the end of the connection" signals the end of the request.
The majority of HTTP queries are bodyless GET requests. To test different hooks that interact with such requests and to adequately stress the proxy code, it is crucial to simulate requests containing bodies. POST or PUT requests are the most common types of HTTP requests with bodies.
For more information on HttpRequestBody - Refer this
Reading about how to return status code 406 in a .NET Core API for requests that require a response in a format not supported by my API, I found that I need to set the following option in the AddMvcCore method:
services.AddMvcCore(options =>
{
options.ReturnHttpNotAcceptable = true;
});
However, I noticed that even if a client requests for an unsupported format, the request is forwarded to the endpoint and only after processing done in Controller that the status code 406 is returned.
I would like to know if .NET Core has a ready-made solution that blocks the request, that is, returns the status code 406 without having to execute the endpoint code. I have found solutions in which Middleware can be written to perform such a task, but I would really like to know if there is an alternative built into the framework itself.
I'm developing a web application based on an Angular 6 client and ASP.NET Core WebAPI for web services.
At the moment (initial development phase) i have a simple architecture that consists of two web services, one that manages authentication and identities, the other one that holds the applicative logic (business logic, updating db, ecc.).
I'm using JWT Bearer token for client authentication.
Everything works fine with my authentication service, but when I try to call the application service I obtain this error in the Chrome browser console:
Failed to load http://localhost:59207/api/Files/Upload: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. The response had HTTP status code 500.
This error is preceded by another one:
POST http://localhost:59207/api/Files/Upload 500 (Internal Server Error)
Is, in some way, the second error I get related to the Internal Server Error it is preceded by?
I test my POST call from Postman and everything works fine, no server-side errors and the data i want back from my service is returned.
I already put in place everything I know about CORS in ASP.NET Core.
Startup class method named "ConfigureServices" contains, as first row:
services.AddCors(options =>
{
options.AddPolicy("AllowAll",
builder =>
{
builder
.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials();
});
});
Then this is called in the "Configure" method:
app.UseCors("AllowAll");
Also I put the EnableCors Attribute on every controller class like this:
[EnableCors("AllowAll")]
Anyone has an idea of how I can get out of this mess?
From what I get, this is how CORS is intended to be used and I already got it running this way on other projects (but never with ASP.NET Core 2).
Thank you in advance
This may not be an answer to your situation, but I've run into this issue quite often in the past. It's a Chrome issue when talking between two localhosts upon POST requests.
Try using another browser and see if it works; if so, you can continue using Chrome by disabling Security
chrome.exe --user-data-dir="C://Chrome dev session" --disable-web-security
hope this helps.
I was trying to throw a quick WCF WebAPI project together up on AppHarbor tonight and ran into some issues. The WCF API is couched inside an empty MVC3 project just like is demo'd on the WCF CodePlex site. https://github.com/jptoto/Postmark-Response-Code-Generator The API itself is quite basic, when you type an http response error code on the end of the url the response will be the proper error code. So, for example, using http://responsecodes.appharbor.com/api/response/405 in Fiddler or some other http client will return the proper error response for a 405 error. (This API is just a convenient way to test with proper error responses).
Anyway, no matter what I try I get 404 errors from AH. I can't tell if the routing isn't working on what. When I download the built code from AH and run it locally inside IIS it runs fine, no problem.
If AH just doesn't support some kind of routing that is in WebAPI Preview 6 that's fine. I just want to cover all my bases. Thanks!!
It seems that you are using the wrong URL and that your app is running here: http://responsecodes.apphb.com/api/response/406
(apphb instead of appharbor)