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)

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.

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

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 の制限に依存すると思われるが、これを任意で変更できるようにしてほしい。

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.

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.

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.

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.

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.

Hi,

I've seen some compatibility issues with the x-forwarded-for header as it comes in on the format IP:Port rather than just IP. It would be useful to be able to adjust this header to just provide IP without the port. I think this should be adjustable, so IP:Port or just IP being available options rather than just one or the other.

This would help x-forwarded-for being easy to parse on systems that only expect the IP to be sent through.

Thanks,

Neil

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.

Hi,
We currently have VMSS running inside a public Load Balancer, that ensures all the apps have the same Public IP address. This is important for us, as we need to be able to publish our IP Addresses for all clients to whitelist.

We really want to move to using the Application Gateway, but can't because it doesn't support static Public IP addresses.

I don't believe there is a work around either?

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