Não quero fazer nada de especial ou complicado em relação ao Windows 8 e fixação, só não quero ver as mensagens 404 Não encontrado enquanto o IE procura browserconfig.xmlrolar em meus arquivos de log.
Existe um browserconfig.xmlarquivo trivial que posso colocar em meu root que satisfaça o IE e atue como um bom marcador de posição, caso eu decida adicionar mais tarde um suporte melhor para o Windows 8?
Respostas:
Eu adicionei o metacódigo à minha cabeça, mas ainda estou recebendo solicitações de browserconfig.xml também.
Então eu acho que a melhor maneira é; segundo eles: http://msdn.microsoft.com/browserconfig.xml
<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
<msapplication>
</msapplication>
</browserconfig>Há um exemplo na referência do esquema de configuração do navegador da página MSDN da Microsoft .
Você coloca o browserconfig.xmlarquivo na pasta raiz do servidor web.
Você também pode incluir:
<meta name="msapplication-config" content="none"/>
em seu HTML para evitar que o IE procure por esse arquivo, se essa for uma opção para você que também possa funcionar.
A solução mais fácil é usar apenas o criador de arquivos oficial do Microsoft Browserconfig.xml: http://www.buildmypinnedsite.com
Você pode construir um arquivo xml completo e receber imagens de todos os tamanhos de seu logotipo em apenas 3 etapas. Acabei de fazer isso para o meu site e levou apenas 2 minutos.
Ele irá gerar um arquivo browserconfig.xml completo e fornecer todas as imagens com título em um único arquivo zip.
Editar 08/01/2015: Acabei de encontrar outra opção: http://realfavicongenerator.net/
A vantagem deste site são os geradores do seu navegadorconfig.xml E todos os seus ícones apple-touch- *, favicon etc. Basicamente, um site único para gerar tudo de uma vez.
Adicionar uma metatag pode ou não funcionar. Adicionamos essa tag, mas ainda recebíamos erros 404 para browserconfig.xmlsolicitações o tempo todo. No final decidimos fazer um xml simples.
Nossa browserconfig.xmlaparência é assim e basicamente diz onde 4 imagens estão localizadas.
<?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>E coloque isso em seu html:
<meta name="msapplication-config" content="/browserconfig.xml" />E agora está bem
Você também pode simplesmente adicioná-lo ao seu HTML e definir a configuração como "nenhum" assim:
<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"/>
Fontes:
http://samples.msdn.microsoft.com/iedevcenter/PinnedSites/scenario1.html https://msdn.microsoft.com/library/dn320426
Existe uma terceira maneira de evitar que browserconfig.xmlseus arquivos de log contenham erros 404. Você pode retornar um valor nulo (444) do servidor e desligar o registro apenas para aquele local. Isso é relevante porque favicon.ico faz a mesma coisa, ignorando as metatags head e o navegador que as chama (também gerando um 404). O problema é maior do que apenas este arquivo indesejado.
Para sua questão específica de prevenção de erros 404 em seus logs em browser.xml - para NGINX, você pode criar um novo arquivo /etc/nginx/snippets/e então #includeesse arquivo em seu /etc/nginx/sites-available/example.orgarquivo dentro do bloco do servidor.
Exemplo: /etc/nginx/snippets/block-known-errors.confpossui o seguinte conteúdo:
location ~* /(favicon.ico|browserconfig.xml)$
{ access_log off; log_not_found off; return 444; }
Então, em sua configuração, /etc/nginx/sites-available/example.orgvocê adicionaria:
include /etc/nginx/snippets/block-known-errors.conf;
Observe que a especificação de local em NGINX está usando uma expressão regular e não faz distinção entre maiúsculas e minúsculas . E por ser um locationdeve estar dentro da serverespecificação.
Na prática, aninhamos nossos includes na /etc/nginx/snippets/pasta e temos um includes global e outros includes para sites específicos, dependendo dos requisitos de segurança / tecnologia. Isso permite que nossos endpoints consertem um problema global quase imediatamente, adicionando um arquivo ou editando um arquivo existente para gerenciar nossos logs.
Há um limite para o que você pode ver com OSSEC e uma pilha ELK.
Tenho certeza de que o mod_rewrite no Apache também pode fazer isso.