No quiero hacer nada especial o complicado con respecto a Windows 8 y la fijación, simplemente no quiero ver los mensajes 404 Not Found ya que IE busca browserconfig.xmldesplazarse en mis archivos de registro.
¿Existe un browserconfig.xmlarchivo trivial que pueda poner en mi raíz que satisfaga a IE y actúe como un buen marcador de posición en caso de que decida agregar más tarde un mejor soporte para Windows 8?
Respuestas:
Agregué el metacódigo a mi cabeza, pero todavía recibo solicitudes browserconfig.xml también.
Entonces creo que la mejor manera es; según ellos: http://msdn.microsoft.com/browserconfig.xml
<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
<msapplication>
</msapplication>
</browserconfig>Hay un ejemplo en la referencia del esquema de configuración del navegador de la página MSDN de Microsoft .
Pones el browserconfig.xmlarchivo en la carpeta raíz del servidor web.
También puede incluir:
<meta name="msapplication-config" content="none"/>
en su HTML para evitar que IE busque este archivo, si esa es una opción para usted que también podría funcionar.
La solución más sencilla es utilizar el generador de archivos oficial Microsoft Browserconfig.xml: http://www.buildmypinnedsite.com
Puede crear un archivo xml completo y recibir todas las imágenes de tamaño de su logotipo en solo 3 pasos. Lo hice para mi sitio y solo me tomó 2 minutos.
Generará un archivo browserconfig.xml completo y proporcionará todas las imágenes tituladas en un solo archivo zip.
Editar 1/8/2015: Acabo de encontrar otra opción: http://realfavicongenerator.net/
El beneficio de este sitio web son los generadores de su browserconfig.xml Y todos sus íconos apple-touch- *, favicon, etc. Básicamente, un sitio web integral para generar todo una vez.
Agregar una metaetiqueta podría funcionar o no. Agregamos esta etiqueta, pero seguimos recibiendo errores 404 para browserconfig.xmlsolicitudes todo el tiempo. Al final decidimos hacer un xml simple.
Nuestro se browserconfig.xmlve así y básicamente solo dice dónde se encuentran 4 imágenes.
<?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>Y pon esto en tu html:
<meta name="msapplication-config" content="/browserconfig.xml" />Y ahora esta bien
También puede agregarlo a su HTML y establecer la configuración en "ninguno" de esta manera:
<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"/>
Fuentes:
http://samples.msdn.microsoft.com/iedevcenter/PinnedSites/scenario1.html https://msdn.microsoft.com/library/dn320426
Existe una tercera forma de evitar que se browserconfig.xmlllenen sus archivos de registro con errores 404. Puede devolver un valor nulo (444) desde el servidor y desactivar el registro solo para esa ubicación. Esto es relevante porque favicon.ico hace lo mismo ignorando las etiquetas meta head y el navegador que lo llama (también genera un 404). El problema es mayor que solo este archivo no deseado.
A su pregunta específica sobre la prevención de errores 404 en sus registros en browser.xml, para NGINX, puede crear un nuevo archivo /etc/nginx/snippets/y luego #includeese archivo en su /etc/nginx/sites-available/example.orgarchivo dentro del bloque del servidor.
Ejemplo: /etc/nginx/snippets/block-known-errors.conftiene el siguiente contenido:
location ~* /(favicon.ico|browserconfig.xml)$
{ access_log off; log_not_found off; return 444; }
Luego, en su configuración /etc/nginx/sites-available/example.org, agregaría:
include /etc/nginx/snippets/block-known-errors.conf;
Tenga en cuenta que en la especificación de ubicación en NGINX se utiliza una expresión regular y no distingue entre mayúsculas y minúsculas . Y debido a que es un locationdebe estar dentro de la serverespecificación.
En la práctica, en realidad anidamos nuestras inclusiones en la /etc/nginx/snippets/carpeta y tenemos una inclusión global y otras inclusiones para sitios específicos según los requisitos de seguridad / tecnología. Esto permite que nuestros endpoints solucionen un problema global casi de inmediato agregando un archivo o editando un archivo existente para administrar nuestros registros.
Solo hay una cantidad limitada de cruft que puede ver con OSSEC y una pila ELK.
Estoy seguro de que mod_rewrite en Apache también podría hacer esto.