Currently 503 errors (service unavailable) present a blank white page with "service unavailable" to the users which is far from professional for us. It would be far better if we could provide a custom 503 page which would include a logo etc., and some text along the lines of "We apologise for the inconvenience, we are working on it. These issues usually resolve in about five minutes. please contact support for further help if required." or something similar.... This error might be caused by Azure network issues, so away from the web app instance.

It would also be helpful if this were possible for 403s as well. However 503 is the most important.

I have raised this idea before, but it seems to have disappeared.

I am pretty surprised that we cannot do this already.

Thanks.

For multi-tenant applications, we require the ability for Azure to support double wildcard custom domains.

Single wildcard custom domains are currently well supported, i.e.

*.mydomain.com

catches all unmapped, single subdomain urls e.g. level1ex.mydomain.com, level2ex.mydomain.com etc

The issue (which isn't documented: see forum post below) is that secondary level wildcards are not supported at all by Azure:

e.g. www.level2.mydomain.com will result in a 404 error.

Why is this important? in a multi tenant environment, with lots of customers on different subdomains, it is best from an end-user perspective to support a www. subdomain prefix, as that's what 99% of non-technerati do when navigating to a website!

i.e. typing in www.level2.mydomain.com should be resolvable by Azure, just as single-level domains are, and not result in a 404

https://social.msdn.microsoft.com/Forums/azure/en-US/4196087d-0ef9-44dc-9192-73e434bdb194/second-level-subdomains-wildcard-domains-on-azure-dont-work-as-expected?forum=windowsazurewebsitespreview

Restricting to .pfx files for certificates makes sense in the context of TLS/SSL.

The thing is, we're using this same cert functionality for non-SSL certs that we just want to have available for the website (like pfx files for encryption or cer files for communicating with other systems that use cert based auth). With Cloud Services, whether it was an SSL cert or a non-SSL cert, pfx or cer, they were all configured the same way and made available via the cert store. With Azure websites, the response we've got is, us the SSL mechanism for pfxs and drop your cers into AppData or something, however this makes the migration from Cloud Services to Azure websites not as seamless requiring us to change code where we look up those certs...

Making this available would make it easier for customers to migrate from Cloud Services to websites.

There are many reasons you may want to have a static IP address for outbound connections. For example, you may be accessing a system which requires you to whitelist IP address in a firewall, such as SQL Database or an external service.

Currently, the only way to get a static IP address for outbound connections is to use App Service Environment. App Service Environments are quite complex, and has a very high price tag. You need at least 4 instances, 2 of which must be P2, meaning you'll pay at least 1000 EUR/month. Paying 1000 EUR/month just because you want a static IP address is obviously ridiculous.

I'm looking forward to being able to use a static IP address without an App Service Environment.

We are seeing some delays in Time To First Byte because OCSP stapling is not active on Azure Web Apps SSL endpoints.
This causes our clients' browsers to call the issuing CA's endpoint before SSL negotiation can really begin.

Stapling would save the client browser from having to make an extra request to the CA checking if the certificate has been revoked.

There is also a potential privacy issue for our clients that the CA will be able to log these requests. If the web server takes care of OCSP on the other hand no requests will be sent from the client to the CA.

The wikipedia article on OCSP stapling explains things pretty well.
https://en.wikipedia.org/wiki/OCSP_stapling

Running webpagetest.org against your site with the browser set to firefox shows the OCSP calls to the CA.

Deploying a Java application to Azure for the first time is not bad, but incremental updates are very painful. The basic functionality works, but it involved multiple steps that really shouldn't be there.

1. Every time that you want to deploy a WAR file, you have to delete the application's exploded directory (ROOT, for example). In order to do this properly, you have to stop the server first. You should be able to simply replace the WAR file (ROOT.war, for example), and have Tomcat take care of updating the application. If you have an application that is large or has a lot of files this process can take your application out of service for a long time (20+ minutes to delete all the files over FTP in my case).

2. There is no easy way to redeploy/restart Tomcat without taking the service out completely. When updating certain classes that may be loaded in memory, you may need to trigger a Tomcat redeploy.

3. When deploying WAR files over GIT (or any of the other deployment methods), it looks like Azure SOMETIMES attempts to have Tomcat deploy the newly uploaded file before it is finished uploading. This results in a partial application deploy and requires to you to restart the server anyway to get it to load properly.

Deploying exploded WAR files via a repository seems to work OK, but classes don't always get reloaded if they change.

4. The Catalina and other tomcat generated logs seem to be locked by the OS (even for reading), and are unavailable via FTP until the site is stopped. This makes debugging issues very difficult, as errors can't be read while the server is running.

We've recently suffered a 3 hour outage on our web app due due to the process servicing the web app continuously crashing. After escalating the issue and working with an escalation engineer we have not been able to diagnose the cause (access violation but unfortunately the crash dump was corrupted).

However what we have learned is that even with multiple instances running if this was to happen again the unhealthy instance would not be removed from the load balancing and all requests serviced by that instance would fail. According to the escalation engineer the load balancing just detects infrastructure failures, not application health per instance.

Would it be possible to leverage the existing web test functionality to define a 'health test' for the application? If Azure detects that an instance fails the health test for an extended period of time it could tear down the instance and create a new one?

Currently Testing in Production (TiP) can be used for two purposes: A/B testing or deploying multiple versions of the same website (eg. production and staging).

Some companies like us use TiP only for the second purpose, but as soon as we enable the feature, an additional cookie called "TiPMix" added to our website. The purpose of the cookie is enable A/B testing and help to decide which user should be randomly routed to which slot. We always route 100% of our traffic to the production slot, so no decision have to be made in our case thus we don't need this cookie. (If we want to use the staging slot then we use the x-ms-routing-name query parameter + cookie as the slots feature does NOT depend on the TiPMix cookie).

Despite this cookie is only used server-side by Azure and we only use HTTPS endpoints, the cookie is not set to be Secure, nor HTTPOnly. This causes our website fail on tests by several security scanners:
- https://observatory.mozilla.org/
- https://app.upguard.com/webscan
- https://httpsecurityreport.com/

I attached sample screenshots of the results of these scanners.

Please notice on the screenshots that almost everything else is configured correctly, only TiP causing problems on our website (the scan was executed on a test website configured similarly to our production website).

One of the possible solutions to this issue is not to send TiPMix cookie if 100% of the traffic is redirected to the same slot. It does not require any UI modification on the Azure portal and hopefully does not change the behavior of the A/B testing as 100% of the traffic would go into the same slot regardless the value of the TiPMix cookie. In an optimal case it's basically an additional if condition in "should I send the TiPMix cookie" code: if there is only one 100% slot (everything else is 0%) then do not add the cookie.

Other solution is to add HTTPOnly flag as you only use this cookie from server-side and accessing this cookie from JS is AFAIK not supported anyway. Also add an option to turn on the Secure flag somehow. The latter would probably require UI change, that's why I prefer the first option mentioned above.

To summarize: it would be good if TiP could be configured (or better: set up by default) in a way that does not cause security warnings (or even security risks in some edgecases).