This week I found a new friend in the the Log Stream diagnostics feature in the Azure portal for WebApps. I used it to solve a case where request filtering didn’t work in a website migrated with the Azure Migration Assistant.

The problem

A customer had a website that also contained a ClickOnce app that you could start from the site. ClickOnce is roughly a way of downloading the EXE and files it needs via the browser in a controlled way. Since each EXE has a .config file, the .config file is also downloaded via http(s). Config file extensions is blocked by default, so to allow a .config file to be requested via http you have to allow it in IIS via something called request filtering.

Solution attempt 1

With Azure WebApps, there is no IIS Manager you can use to config the web server. All config changes must go into the Web.config file. Searching the internet told me that the below screenshot was the way to add request filtering in the Web.config file. The <remove ..> element must preceed the <add ..> element to first remove the existing rule. If you don’t have it, the IIS will complain about errors in the config file.

However, success was limited here and trying to browse to my test config-file resultet in a 404 http status. Since the file obviously existed on the server, something must be stopping it from being served.

Log Stream Diagnostics

If this would have been a VM I would have logged in to with RDP and checked the IIS log files to see what happened to the http request and perhaps even used procmon to investigate possible NTFS access problems. In Azure WebApps we have the Kudo portal but lately more and more of the Kudo functionality have started to appear in the Azure portal and Log Stream is one of them. By enabling logging in the Diagnostics settings, you can get a near real-time view into the IIS log and see what is happening.

The request for the test config-file had http status 404.3 which means “MIME type restriction”, ie IIS wants to serve the file to the client but doesn’t know what MIME type to set on it. If that sounds wierd to you, you can think of it as a case of “an allowed file with an unknown file type/extension” (I see what it is but don’t know what to do with it).

Solution Attempt 2

After searching the internet a bit more I added the following lines to my Web.config file to let IIS know that a .config file is really an xml file.

With this addition to the Web.config file, http requests for files with .config extensions works like a charm and the ClickOnce app was able to start on the client without errors.

Wait, wait, you say! Does this mean that users can know access my Web.config and see all secrets, like database connection strings, etc. No, they can’t, because IIS actually blocks files named Web.config.

Summary

The summary of this relatively short blog post of mine is that the Log Stream Diagnostics tool is a real asset when you troubleshoot obstructive deployments on Azure WebApps. Make sure you get use to it if you haven’t already.

References

No refs