Что такое простой / минимальный browserconfig.xml для веб-сайта

Я не хочу делать ничего особенного или сложного в отношении Windows 8 и закрепления, я просто не хочу видеть сообщения 404 Not Found, когда IE ищет browserconfig.xmlпрокрутку в моих файлах журнала.

Есть ли тривиальный browserconfig.xmlфайл, который я могу поместить в свой корень, который удовлетворит IE и будет служить хорошим заполнителем, если я решу позже добавить лучшую поддержку для Window 8?

Я добавил метакод в голову, но все еще получаю запросы browserconfig.xml.

Так что я думаю, что лучший способ; по их словам: http://msdn.microsoft.com/browserconfig.xml

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

Пример можно найти на странице Microsoft MSDN. Ссылка на схему конфигурации браузера .

Вы помещаете browserconfig.xmlфайл в корневую папку веб-сервера.

Вы также можете включить:

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

в вашем HTML, чтобы IE не мог искать этот файл, если вам подходит этот вариант.

Самое простое решение - просто использовать официальный конструктор файлов Microsoft Browserconfig.xml: http://www.buildmypinnedsite.com

Вы можете создать полный xml-файл и получить изображения вашего логотипа всех размеров всего за 3 шага. Я сделал это для своего сайта, и это заняло всего 2 минуты.

Он сгенерирует полный файл browserconfig.xml и предоставит все изображения с заголовками в одном zip-файле.

Изменить 1/8/2015: я только что нашел другой вариант: http://realfavicongenerator.net/

Преимущество этого веб-сайта в том, что он генерирует ваш browserconfig.xml И все ваши значки apple-touch- *, favicon и т. Д. По сути, это универсальный веб-сайт для создания всего один раз.

Добавление metaтега может работать, а может и не работать. Мы добавили этот тег, но по-прежнему получали ошибки 404 для browserconfig.xmlзапросов. В конце мы решили сделать простой xml.

Наш browserconfig.xmlвыглядит так, и в основном он просто говорит, где расположены 4 изображения.

<?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>

И поместите это в свой html:

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

И теперь все в порядке

Вы также можете просто добавить его в свой HTML и установить для конфигурации значение «none» следующим образом:

<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"/>

Источники:

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

Существует третий способ предотвратить browserconfig.xmlзаполнение файлов журнала ошибками 404. Вы можете вернуть с сервера нулевое значение (444) и отключить ведение журнала только для этого местоположения. Это актуально, потому что favicon.ico делает то же самое, игнорируя мета-теги заголовка и вызывающий его браузер (также генерируя 404). Проблема больше, чем просто этот ненужный файл.

Что касается вашего конкретного вопроса о предотвращении ошибок 404 в ваших журналах на browser.xml - для NGINX вы можете создать новый файл, /etc/nginx/snippets/а затем #includeэтот файл в своем /etc/nginx/sites-available/example.orgфайле внутри серверного блока.

Пример: /etc/nginx/snippets/block-known-errors.confимеет следующее содержание:

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

Затем в вашем конфиге /etc/nginx/sites-available/example.orgвы должны добавить:

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

Обратите внимание, что в спецификации местоположения в NGINX используется регулярное выражение и не учитывается регистр . И поскольку это так, это locationдолжно быть внутри serverспецификации.

На практике мы фактически вкладываем наши включения в /etc/nginx/snippets/папку и имеем одно глобальное включение и другие включения для конкретных сайтов в зависимости от требований безопасности / технологии. Это позволяет нашим конечным точкам почти сразу исправить глобальную проблему, добавив один файл или отредактировав существующий файл для управления нашими журналами.

С OSSEC и стеком ELK можно увидеть не так уж много мусора.

Я уверен, что mod_rewrite в Apache тоже может это сделать.