Я не хочу делать ничего особенного или сложного в отношении 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 тоже может это сделать.