Allow A New Mime Type Download on WordPress / Azure

After you allow a new MIME type via editing your functions.php file or using a plugin like WP Add Mime Types, you might find that you can’t download the files when running WordPress on Microsoft Azure.

I ran into this problem recently when adding .gpx and .kml files to my site, but you could encounter similar problems with other types. The error message I was getting when attempting to download the files in a browser was:

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

The problem is that by default, WordPress runs under Microsoft Windows in Microsoft Azure, but IIS does not serve many types of static content by default. The easiest solution, other than trying to modify the configuration for IIS, itself, is to modify the Web.config file for the web application. In the root of your WordPress application folder, you’ll either see no Web.config file (you can use the first example below as a full file), or you’ll see an existing Web.config file you can modify.

The following piece should allow you to download the files you want (adjust for the types of file extensions and MIME types you’re attempting to allow):

My site already had a Web.config file with a rewrite rule, so I actually modified it to be similar to the below example (the name portion is a placeholder):

WCF Proxy Server Authentication

Almost everyone who’s written a .NET application which calls a web service has had to deal with service calls passing through a proxy server. In the past, after generating the service client from WSDL, I’d set up a WebProxy (possibly with NetworkCredential) — which really isn’t all that bad, but somewhat annoying. Now, more ideally, the service calls are via svcutil generated WCF clients. However, handling proxies programmatically in WCF is more difficult since you can’t deal with a nice WebProxy object. You can set credentials via ChannelFactory.Credentials, but this has a drawback — your credentials need to be the same for the proxy and server authentication if they both use the same authentication scheme. The programmatic approach has always struck me as unnatural.

I just discovered a much simpler way to deal with proxies this week. Thankfully, the answer really has nothing to do with WCF. WCF depends on the underlying System.Net subsystem, and by default, .NET clients will not pass their credentials to the default proxy server. This is what had tripped me up in the past. The default errs on the side of security, since you may not want to leak credentials when not necessary. You can instruct System.Net to pass the default credentials via the following config:

If your application is running as a domain user who has access to the proxy server, your WCF, web service, etc. calls will work without further modification. As a matter of practice, I configure my Application Pool identities and Windows Service identities to run under domain user accounts whenever possible.

Sometimes you may need to specify your default proxy if the system cannot autodetect it or you don’t want to use the autodetected proxy. In that case you can do the following (this example also uses default credentials as above):

Using default credentials works in all the situations I’ve encountered, but you may run into the need to specify different credentials in shared hosting environments/etc. To my knowledge, there’s no way to specify particular credentials in .NET configuration files. If you need to specify other credentials for your web proxy and you’re using WCF, you’re stuck specifying them via ChannelFactory.Credentials on your WCF client.