Allow configurable timeout period for Front Door
Currently Front Door forces a 30 second timeout for backend requests. This can severely restrict the usefulness of the service in production systems. It would be great to have the timeout period configurable to allow for a longer period of time. My understanding is that the Azure Load Balancer, which sits in a similar space as Front Door, defaults to a 4 minute timeout period.
Check out the documentation here – https://docs.microsoft.com/azure/frontdoor/front-door-troubleshoot-routing#503-response-from-front-door-after-a-few-seconds
Also this is now available in the portal as well under “Front Door designer” —> Settings tab
Raghavendra Hegde commented
Can the timeout limit increased?. 4 min timeout for some of the synchronous use cases are not enough.. It will be helpful atleast for 1 hour if not 2 hours.
Hemant Sharma commented
If anyone considering this..and missing this mentioned setting. Find snapshot to locate the same.
"The value must be between 16 and 240."
Really? Made a config and limited it? omg
Yes I found it in settings under the designer. Do not enter either of the pool or routing sections. The settings button is on the base designer page
Rian Finnegan commented
It's been over a month since this was market complete, but there is still no 'Settings Tab' in the Front Door Designer
Simone Locatelli commented
There's no Settings tab or field related to the "sendRecvTimeoutSeconds" property.
Please include instructions on how to update the setting
Rolf Janssen commented
I do not see this setting in the Settings tab.
"Also this is now available in the portal as well under “Front Door designer” —> Settings tab"
Where is this? I can't see this in the portal?
Cedric BRAVO commented
It is now accessible from azure cli !
>az extension add --name front-door
>az network front-door update --name [FrontDoorName] --resource-group [ResGroupName] --send-recv-timeout 60
Jason Barlow commented
So I talked to a Microsoft Rep at the company I work at today and he directed me to the following website https://github.com/Azure/azure-rest-api-specs/blob/master/specification/frontdoor/resource-manager/Microsoft.Network/stable/2019-05-01/frontdoor.json
He said that currently there is not a way to adjust this value through the portal or azure cli but you can adjust it through a rest api for front door. After spending 2 hours working on this I figured it out. First you need to get a bearer token from you azure ad. Once you get the bearer token you can call the get route for FrontDoor
Then you will copy the body of the response and make a PUT request with an update made to
By default this is either null or 30 seconds.
Here is the json doc for this property
"description": "Send and receive timeout on forwarding request to the backend. When timeout is reached, the request fails and returns.",
I hope this helps
Vivek Malhotra (BING) commented
+1 for making it a configurable option. We spent lot of time debugging an issue where we felt exception is occuring at backend and in the end, it turned out to be default timeout in afd while everything worked normally (although little slower expectedly) in the backend!
Rajinder Singh commented
Any ETA on when this will GA? This is a big problem for us.
I have an Angular application running on Azure Web Apps, that anguar application make the browser hit several APIs on Azure Web Apps as well. Front Door is failing miserably with this 30 second time out. My API also runs cpmplex process that takes a little over 30 seconds sometimes, but to my surprise they aplication is failing even when the response is less than 30 seconds, probably because the firewall needs some time to process it, and front door needs some time to route it. according to my API insight the longest it took to reply was 11 seconds, but it still fails. All my calls are asynchronous, it is an Agular app. all my infrastructure is configured via powershell, please add the option to configure the time out not just via the API please make it available via Powershell.
Any update on when this will be available? We were in the process of rolling out Front Door to our application but had to roll it back as a result of the timeout limitation. Need to understand if we need to change our approach or what is the tentative release date.
Dan Strzelec commented
Is there an update on this item? This timeout issue is a show stopper for me as well. We have many requests to our API to generate large reports that take in excess of 30s to process.
This is a showstopper for us too. There is a case, in our we app, when the timeout exceeds 30s. The request is issued by a popup window where the long delay doesn't look particularly "user unfriendly". With the Front Door, the user receives an error (the Front Door service unavailability page) in the popup. A workaround could be to re-implement the client/server interaction so it became asynchronous, but, currently, such a refactoring is problematic for us.
Microsoft, please let us configure the timeout! (And not the way you let us configure the request body SIZE limit for the Application Gateway based WAF: its maximum of 128kb is "utterly" insufficient, and there is no way to avoid the check for specific URLs.) For the TIMEOUT, the maximum should be no less than an hour - for guaranteed allowance.
In some scenarios, we aren't even going to use the load balancing capability of the Front Door: just the firewall one. Alas, we can't do even that!
We are a company that's been developing accounting and planning software for about 30 years.
We've migrated our software to Azure, and are trying to implement a Windows Application Firewall to be protected from OWASP top 10 vulnerabilities. Our attempt to implement the WAF based on the Application Gateway has failed because of the request body size limit. Even using the Firewall Policy (custom rules), it is impossible to define requests that would be exempt from the size check. Our attempt to implement the WAF based on the Front Door has failed because of the request timeout limit. The failure is preventing us from the implementation of our systems on MS Azure platform *for demanding customers*. We've been able to run our software as an Azure cloud service (classic) for years.
Thank you for your attention to this issue!
We had to rollback as well because of this issue.
Brad Darnell commented
I see this was started. Any update on when this will be available? We were in the process of rolling out Front Door to our application but have now had to roll it back as a result of this issue. Need to understand if we need to pivot to a new approach.
Andrew Innes commented
You asked: "Can you explain your scenarios a bit more? Azure Front Door is different than Azure Load Balancer particularly for the fact that it is Layer 7 i.e. HTTP/HTTPS. So, waiting and not getting a feedback from the backend/origin/app server for 30 seconds for a web request is unusual."
I think you are assuming a user interaction scenario, where 30s would indeed be a worryingly long time. However there are plenty of API scenarios where those kinds of considerations aren't relevant. In our case we have a Speech-to-Text API that is used as part of various automated batch-processing workflows by different customers, where people may post videos that are multiple GBs in size. A common pattern is to post the files as a URL reference to blob storage, which of course is very quick, but our preferred logic is to immediately fetch the blob and perform some validation steps before accepting the transcription job request. It can easily take more than 30s to fetch a large blob; from our perspective that is an arbitrary limit we would not impose by choice (we would probably set it to 5 or maybe 10 minutes).
As another example of why this is useful: we have an application that uses long polling to handle event dispatch. Any application using Microsoft .NET SignalR may use long polling when web sockets aren't available (as they don't appear to be with Front Door).
Because long polling requests wait server-side, they can be expected to have multiple-minute timeouts without this being and indication of performance issues or failed requests.