When using an Application Gateway to provide SSL offloading for applications hosted on IIS / IaaS, there is no native option to redirect HTTP requests to HTTPS. Without redirection or a listener on 80 for the host name, users receive a 404 response. This leads to developing a more complex network topology to handle inbound HTTP request to the host name.

Possibly allow for an additional option on a listener, that will allow for returning a redirect HTTP code with the proper HTTPS URL, creating a clean/seamless experience for the end user.

PathBasedRouting is nice, but not super great without the ability to rewrite paths. I am trying to front a Service Fabric cluster, where multiple HTTP services live on http://+:80, at different path prefixes. Would be nice to use Application Gateway to direct https://api.company.com to http://cluster/api, and https://www.company.com to http://cluster/www

It should be possible to define a list of SSL hostnames. Application Gateway should automatically acquire and renew certificates for all given hostnames (most probably through the HTTP domain validation process).

For every request, Application Gateway should use the correct certificate based on the hostname.

Supporting multiple hostnames is critical to use Let's Encrypt with multi-site routing.

Azure Application Gateway is a nice Service for Load Balancing Layer 7 HTTP and HTTPS traffic. Today, we can only attribute one IP address (Public or Private) to the Application Gateway Deployment. It is fundamental that a Load Balancer can support multiple IP addresses to provide flexibility (Based on many customers feedback)

For the sake of security, it would great if we could get the following tags removed from the AG responses:

< Server: Microsoft-IIS/8.5
< X-Powered-By: ARR/3.0
< X-Powered-By: ASP.NET

Add HTTP/2 support to Azure Application Gateway. HTTP/2 has been around for long enough that this should be supported by now. We were disappointed once again after spending time investigating Azure Application Gateway that this is not supported. We shouldn't have to go backwards to use this service.

In case when the connection is done via Application Gateway, it shows no response when HTTP connection takes over 4 minutes.
I predict the root cause of this issue is due to Azure’s Load Balancer, as it depends on limitations.
Therefore, I ask you to change it so we can make the limitation optional.

(Japanese)
Application Gateway を経由した通信の場合、 4 分間を超える HTTP 通信が発生すると、応答を返さなくなる。
この動作は、Load Balancer の制限に依存すると思われるが、これを任意で変更できるようにしてほしい。

We have requirements from customers to restrict access via their company subnets. It would be very nice if the App Gateway supported not only the SSL offload but the ability to apply ACLs to allow or deny access via a defined network range using X-FORWARDED-FOR headers.

It should be possible to select HTTPS certificates from Azure Key Vault. Since Azure Key Vault support auto-renewal of certificates, Application Gateway should also automatically update the certificates.

Application gateway has a backend http setting limit of 20.
We want to use it in front of Service Fabric and legacy cloud applications.
Each of our service fabric apps runs on its own port and so requires a probe, http setting and url rule.
We exceeded the 20 fairly rapidly.

Legacy client applications that call our services are stuck on antiquated platforms like Java 1.6. These clients cannot use the latest/greatest TLS ciphers. There is no intersection of supported ciphers between vanilla Java 1.6 and those ciphers permitted by Application Gateway.

Fighting to get customers to patch and upgrade their ERP and other systems in the name of security is often a time-consuming and losing battle.

The ability to enable the ciphers of our choice, perhaps (dare I dream?) by source IP, would be an amazing boon to supporting legacy clients.

Instead of requiring an App Service Environment, or Virtual Machines running IIS, allow us to put in the FQDN/IP Address of our Azure App Services.

I'm experimenting with using App Gateway as a frontend server to do URL routing to one Windows App Service and one Linux App Service, via the portal. I'm an hour in to this process because each and every step takes many minutes to complete.

When running MVC applications with federated authentication with IdPs like Azure AD B2C, the OAuth response coming back from AD is always greater than 2048 character url length. This becomes limitation of AG as AG can not be used for application doing federated authentication with various IdPs including Azure AD B2C.

Please remove the 2048 character limitation as well any other request size limitation which could truncate url as well as request body including cookies etc.

It would be nice to be able to use HEAD requests for health monitoring instead of full GET

My ApplicationInsights logs show all the health requests done by AG to monitor the health of the system.
I'd like to have the possibility to recognize health requests through specific headers so that I can skip standard HTTP pipeline and immediately return 200 status code, without logging the request

To reduce the number of 502 bad gateway requests that are served up Application Gateway should have a retry policy for failed requests, allowing it to move the the next available server. This would be especially useful when used in front of Service Fabric where services are moved between servers.