I am using an api which takes more time to give response. If I tested the web api that was deployed in IIS from postman, It works without any time out. If I tested the same api that was deployed in azure, It gave me timeout.
Somewhere I read that you need to set the timeout in client application. I used postman in both cases. I verified the timeout for postman. It is infinity.
Can you give me the solution?
I think that you hit the default timeout of Azure Web Apps (i think it is 3 minutes, if i remember correctly). Could you set SCM_COMMAND_IDLE_TIMEOUT from the portal - web app settings => app settings => add the setting with the needed value (to say 360 (in seconds)). Reference.
Related
I hosted a Web Api to azure app service. Everything works fine when I published it.
After a couple of days, the Web Api stops responding. But my app service is still running.
Even added application Insight Logs to all the code, to all the catch blocks, even then its not helpful.No exception was logged to date.
Checked the following, but doesn't seem to be helpful.
Thread Count of app service.
CPU time.
and this was the error when I tried to hit from postman after my web API is down.
<html><head><title>500 - The request timed out.</title></head><body> <font color ="#aa0000"><h2>500 - The request timed out.</h2></font> The web server failed to respond within the specified time.</body></html>
When I restarted my app service the web API started working and stops again after a couple of days.
I think your app service is being idled out due to inactivity . Please set always on to be true in the general settings in configuration blade , you can check out link
App service configuration.
I have ASP.NET Core Web API deployed as App Service on Azure. App Service is set up to require Client Certificate. Also AlwaysOn for App Service is set to True.
Issue is that first request with small payload sent to Web API takes approximately 2-3 seconds, and with large payload timed out. But after first small successful request, next one with large payload executes in less than a second. After some period of inactivity the issue occurs again, and first request to Web API again either takes time or timed out.
When Require Incoming Certificate is disabled, no issues with first request execution time, it executes quite fast always.
Web apps are unloaded if they are idle for a set period of time.
Quoted from official docs:
The downside is that the response to the first request after the web app is unloaded is longer, to allow the web app to load and start serving responses.
If you're using a Basic and Standard service plan, you can turn on the Always On setting to keep the app always loaded:
In the Azure portal, go to your web app.
Select Application settings.
For Always On, select On.
We have an Angular5 application with a DotNet OData backend API. The application is hosted in a Web Application with a virtual directory for the Angular5 app and another virtual directory for the DotNet backend. The web application is secured by Azure AD, with an Azure AD Application defined for the web site.
This all works perfectly. We have no authentication code in the front end (except for 'withCredentials: true' set in the service calls) but apparently having the whole application protected by Azure AD makes the front end able to call the backend without issue (Azure makes you authenticate when you access the Angular5 front end).
The problem comes when we try to develop the front end. When developing Angular5 one needs to run the Angular5 code locally, so I've set up a web app which hosts only the backend code and point the local configuration for the Angular5 app there. This fails with the first backend call with a 401. One of our developers discovered that if you simply plug in the URL to the backend with the same browser (i.e. copy the failing call from the browser network developer tab into a new browser tab in the same browser) you will go through the authentication process and then when you run the local Angular5 app again it works. We thought we had found a workaround until we noticed that for some reason this only seems to fix the "read only" calls. GET works, OPTIONS works but POST fails with a 401. I put some debugging code in the backend but it seems this code does not even get called (i.e. Azure, not our backend, is blocking the call).
So I've tried to figure out how to get the local Angular5 instance to behave as the one hosted by the Web app but I can't figure out what I need to be doing. I have also been unable to find anyone else doing this so I can't find a solution.
I have tried various solutions of actively getting a token (e.g. setting up /.auth/me, using adal5 to "login", etc.) for the front end but it seems every possible solution is defeated by CORS in the end. Our backend has an Allow-Origin for localhost:4200 but this doesn't apply to login.windows.com for the authentication step. I tried putting localhost:4200 in the CORS setting on the Azure Web App but then it complains about an Allow-Authentication header being missing and I have no way to force Azure to provide that. I read online that this is happening because Azure didn't expect people to be using "cookie authentication" so after some research I found that "cookie authentication" was being used because of the "withCredentials: true" calls, so I changed all of those to false. Then the Allow-Authentication failure goes away but I just run into more CORS failures during the authorisation (login.windows.com).
So I'm really stuck here. I can't believe I'm the only person on earth who's trying to run a local instance of Angular5 against an Azure AD secured Azure Web app backend but I can't find any examples anywhere of people successfully doing this. I also would like to avoid having to do some elaborate local authentication because the code works perfectly as-is when hosted on the same Azure Web app as the backend. Does anyone have a setup like I describe that is working?
I have a Web site deployed on Azure Web App. My web site gets very slow at times. This behavior is random.
On checking IIS Logs during the period of slowness, I found few requests coming in where the Client IP Address is blank (It shows "-").
The response time of these requests runs into minutes and finally they result into HTTP 500 error. This happens only for the requests where c-ip is blank.
All other requests that have a Client-IP address are processed successfully. But because of the bad requests my application becomes very slow. I have to restart my Web App to resolve this issue.
What could be the possible reason behind these requests having a blank Client IP Address ? Could this be a malicious attack on the web site ?
Difficult to say. Could you add Application Insights service to your project? It allows you to see what is going on before and after 5 minutes of "this" request. The second reason can be the mode of your Azure Web App - is it free or shared or standard?
After AI added, you could share some more insights, because it is important to know what is that request about, not just the fact that it was processed.
https://azure.microsoft.com/en-us/documentation/articles/app-insights-start-monitoring-app-health-usage/
I have a web role that hosts 4 MVC 4 sites. One of the sites (let's call it the API site from now on) uses both MVC and Web API. When I upgrade the web role, the Web API controllers from the API Site returns a 500 Internal Server Error to all requests. The MVC controllers work as expected and I know the request is getting at least as far as the Application_BeginRequest method of the global.asax. I'm not seeing anything logged in my Elmah log. The only hint I have of anything being wrong is the following in the event log:
The application '/' belonging to site '1' has an invalid AppPoolId 'DefaultAppPool' set. Therefore, the application will be ignored.
As web roles use App Pools with guids as identifiers I don't know where this is coming from.
What is most confusing is that once I recycle the app pool for the API site (which is a guid) everything starts working correctly.
I've tried recyling the app pools as part of a startup task on the role, but that doesn't seem to make any difference.
Any suggestions about what I can do to get Web API to start correctly?
I never did find what was causing this issue.
It got to a point where I could deploy from my machine and not get the problem, but my colleague could not.
We tried comparing the contents of the .cspkg files that were produced, but didn't find any differences.
We are now both able to deploy the project with no problems.
My suspicion is that this was resolved when we upgraded the Azure SDK and tools on our machines.