I'm creating an API using ASP.NET Web API 2. Everything looks okay but in some cases, after getting an error 400, all the next requests return that same error 400 reponse even if the requests are different.
If I restart IIS, redeploy the API or just changing one space in web.config, the request works fine until I get another error 400 somewhere and the problem starts again.
It looks the error 400 response is cached somehow...
Did anyone have this problem and know how to fix it?
I found solutions on stack overflow may b this can help you.
Configure IIS Express
I was having a single shared static DbContext instance.
I changed to one instance of DbContext for each of my scopes and got rid of the static DbContext and instead create and dispose of it after each SaveChanges(Async) call.
Now everything works fine. Hope it helps.
Related
I have a windows app to test connecting to a 3rd party web service.
I've created a service reference using the wsdl that was provided.
The way the web service will work is a 4 step process.
Method call to get session ID.
Method call to pass arguments
Method call to execute arguments.
Method call to get results.
Now here is the strange part:
I can make the first call no issue.
Calls 2 and 3 do not work from my . net appliaction.
I get the error:
Error in deserializing body of reply message for operation 'setArguments'. End element 'Body' from namespace 'http://www.w3.org/2003/05/soap-envelope' expected. Found element 'ns:setArgumentsResponse'
I am at a total loss with this.
What I've done.
I am capturing my post in Fiddler.
When I examine the body everything looks correct.
If I take the same response that I captured and post it in Fiddler it works.
I've tried the this in Python at it works.
Is there some obscure setting that I could possibly be missing in my application?
My findings in step 1 should prove that I am creating a valid request. Could . NET possibly be choking on the response?
Any suggestions would be appreciated.
FYI:
binding="customBinding"
I've also tried basicBinding and got the same results.
EDIT:
I just wrapped a try/catch around each method and when I call method 4 I get a result. So the error must be on the response. Right?
Issues appears to be that I am consuming a Java web service.
I originally added it as a Service Reference which is causing my serialization errors on the response.
I removed this reference and re-added a Web Reference and it appears to be working without the serialization error.
I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?
Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.
While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole problem.
I've discovered something peculiar that's been going on for the past 2 days.
I'm returning back custom JSON message in my Web API 2.0. E.g. when there's been an Unauthorized Response (HttpStatusCode 401)..it's only returning back the HttpStatusCode and NOT the JSON.
Simply put, anything apart from a HTTP Status Code 200 is NOT returning back the custom JSON that I've explicitly put in my ActionHandlers to return back.
This has happened recently, in the past 2 days. I've tested my code locally and I'm getting the expected output I need..the custom JSON error messages but as soon as I publish to one of my slots whether it be production or dev..only HttpStatus Codes are being returned.
Can anyone verify this for me? I need a way to sort this issue out or atleast have Azure take a look at this and tell me what to do. I suspect it's been an Azure update which I'm unaware of.
Probably some kind of customErrors logic kicks in when you are remotely testing your site. Those logics are usually disabled when browsing locally.
Check your configuration. Under IIS, there is also the httpErrors configuration which may interfere.
And have you set TrySkipIisCustomErrors to true when your code yields an error responses?
Ok, so I've figured out the issue.
Upgraded Visual Studio to 2015 to get the .NET Framework to use 4.6.
Changed all of my projects in the solution to point to 4.6, re-compiled, published and finally tested.
Errors are returning back JSON now too.
IMO, Azure could've atleast sent us an update. Anyways, posting this answer so hopefully anyone else using Web Api can easily forgo this issue.
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)
I have some silverlight code that calls a WCF service which then uses the Entity Framework to access the database and return records.
Everything runs fine but ... when I replace the Entity Framework code with classic ADO.NET code I get an error:
The remote server returned an error: NotFound
When I call the ADO.NET code directly with a unit test it returns records fine so it's not a problem with the ADO.NEt code
I used fiddler and it seems to say that the service cannot be found with a "500" error.
i don't think it's anything to do with the service as the only thing I change is the technology to access the database.
Anyone know what i'm missing here?
'NotFound' is a generic error message that could mean just about anything. If you are absolutely positive that you haven't changed the service interface, then the likely candidate is an exception is being thrown from within your service. Are you sure that the collection type that contains the data you are trying to return hasn't changed, i.e. from List< OfSomthing> to List< OfSomethingElse>?
In any case, something i have found invaluable for tracking this sort of issue is the Service Trace Viewer tool from Microsoft. Read all about it right here, all it takes is some simple changes to your web.config to enable the logging.
John Papa has a great article from MSDN Magazine Data Performance and Fault Strategies in Silverlight 3 that explains this issue and offers a solution. Due to browser limitations, error code 500s aren't routed properly. His solution modifies the outgoing HttpResponse Message back to a 200 for all Silverlight 500 responses.
If you are still stuck, you may want to try making the call to the service from the machine hosting the service. IIS by default returns much more information about what might have gone wrong when the call is from the local machine. (I believe this can be changed, but don't know for sure.)
try to add
HttpWebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
to the Application startup event of the Silverlight app.
It should give you detail of what the real error is rather than NotFound. In my case, i was missing the clientaccesspolicy.xml resuired for cross domain requests.
How to: Specify Browser or Client HTTP Handling