What is a simple/minimal browserconfig.xml for a web site

Question

I added the meta code to my head, but I'm still getting browserconfig.xml requests too.

So I think best way is; according to them: https://docs.microsoft.com/browserconfig.xml

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
    <msapplication>
    </msapplication>
</browserconfig>

There is a sample on Microsoft's MSDN page Browser configuration schema reference.

You put the browserconfig.xml file in the root folder of the web server.

You can also include:

<meta name="msapplication-config" content="none"/>

in your HTML to prevent IE from looking for this file, if that is an option for you that might work as well.

The easiest solution is actually to just use the official Microsoft Browserconfig.xml file builder: http://www.buildmypinnedsite.com

You can build a full xml file, and be given all the sized images of your logo in just 3 steps. I just did it for my site and it only took 2 mins.

It will generate a full browserconfig.xml file, and supply all the titled images in a single zip file.

Edit 1/8/2015: I just found another option: http://realfavicongenerator.net/

The benefit of this website it is generators your browserconfig.xml AND all your apple-touch-* icons, favicon etc. Basically a one stop website for generating everything once.

Adding a meta tag might or might not work. We added this tag, but we still received 404 errors for browserconfig.xml requests all the time. At the end we decided to do a simple xml.

Our browserconfig.xml looks like this and basically it just tells where 4 images are located.

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
    <msapplication>
        <tile>
        <square70x70logo src="/mstile-70x70.png"/>
        <square150x150logo src="/mstile-150x150.png"/>
        <wide310x150logo src="/mstile-310x150.png"/>
        <square310x310logo src="/mstile-310x310.png"/>
        <TileColor>#8bc53f</TileColor>
        <TileImage src="/mstile-150x150.png" />
        </tile>
    </msapplication>
</browserconfig>

And put this in your html:

<meta name="msapplication-config" content="/browserconfig.xml" />

And now is okay

You could as well just add it to your HTML and set the config to "none" like this:

<meta name="msapplication-TileColor" content=" #009900" />
<meta name="msapplication-square70x70logo" content="images/smalltile.png" />
<meta name="msapplication-square150x150logo" content="images/mediumtile.png" />
<meta name="msapplication-wide310x150logo" content="images/widetile.png" />
<meta name="msapplication-square310x310logo" content="images/largetile.png" />
<meta name="msapplication-config" content="none"/>

Sources:

http://samples.msdn.microsoft.com/iedevcenter/PinnedSites/scenario1.html https://msdn.microsoft.com/library/dn320426

There is a third way to prevent browserconfig.xml from filling your log files with 404 errors. You can return a null value (444) from the server and turn off logging for just that location. This is relevant because favicon.ico does the same thing ignoring the meta head tags and the browser calling it (also generating a 404). The problem is larger than just this one unwanted file.

To your specific question of preventing 404 errors in your logs on browser.xml - for NGINX, you can create a new file in /etc/nginx/snippets/ and then #include that file in your /etc/nginx/sites-available/example.org file inside of the server block.

Example: /etc/nginx/snippets/block-known-errors.conf has the following contents:

location ~* /(favicon.ico|browserconfig.xml)$
   { access_log off; log_not_found off; return 444; }

Then in your config at /etc/nginx/sites-available/example.org you would add:

include /etc/nginx/snippets/block-known-errors.conf;

Note in the location specification in NGINX is using a regular expression and is case insensitive. And because it is a location is must be inside of the server specification.

In practice, we actually nest our includes in the /etc/nginx/snippets/ folder and have one global include and other includes for specific sites depending on security/technology requirements. This allows our endpoints to fix a global issue almost immediately by adding one file or editing an existing file to manage our logs.

There is only so much cruft you can see through with OSSEC and an ELK stack.

I am sure mod_rewrite in Apache could do this as well.