¿Cómo puedo hacer que XSLT funcione en Chrome?

google-chrome

Question

here tengo un documento XML que se sirve con un archivo XSL correspondiente. La transformación se deja para que se ejecute en el lado del cliente, sin JavaScript.

Esto funciona bien en IE (shock horror), pero en Google Chrome, simplemente muestra los nodos de texto del documento.

Sé que es posible hacer XSL del lado del cliente en Chrome, como he visto ejemplos de él, pero aún no he podido replicar este éxito yo mismo

¿Qué estoy haciendo mal?

Answer 1

Bueno, no funciona si el archivo XML (comenzando por el PI estándar:

<?xml-stylesheet type="text/xsl" href="..."?>

para hacer referencia a la hoja de estilos XSL) se sirve como "aplicación / xml". En ese caso, Chrome seguirá descargando la hoja de estilo XSL referenciada, pero no se procesará nada, ya que cambiará silenciosamente los tipos de documento de "application / xml" a "Document" (! ??) y "text / xsl" a " Stylesheet "(! ??), y luego intentará procesar el documento XML como si fuera un documento HTML (5), sin ejecutar primero su procesador XSLT. Y Nada se mostrará en la pantalla (cuyo contenido continuará mostrando la página anterior desde la que se hizo referencia a la página XML, y continuará girando el ícono, como si el documento nunca se hubiera cargado por completo).

Puede usar perfectamente la consola de Chrome, que muestra que todos los recursos están cargados, pero se interpretan incorrectamente.

Así que sí, Chrome actualmente solo renderiza archivos XML (con su declaración de hoja de estilo XSL principal opcional), solo si se sirve como "texto / xml", pero no como "aplicación / xml" como debería para el XML renderizado del lado del cliente con un Declaración XSL.

Para los archivos XML servidos como "texto / xml" o "aplicación / xml" y que no contienen una declaración de hoja de estilo XSL, Chrome aún debe usar una hoja de estilo predeterminada para representarlo como un árbol DOM, o al menos como su fuente de texto. Pero no es así, y una vez más intenta renderizarlo como si fuera HTML, y bugs inmediatamente en muchos scripts (incluido uno interno predeterminado) que intentan acceder a "document.body" para manejar eventos onLoad e inyectar algunos javascript controlador en ello.

Un ejemplo de sitio que no funciona como se esperaba (la documentación de Common Lisp) en Chrome, pero funciona en IE que admite XSLT del lado del cliente:

http://common-lisp.net/project/bknr/static/lmman/toc.html

Esta página de índice de arriba se muestra correctamente, pero todos los enlaces conducirán a documentos XML con una declaración XSL básica a un documento de hoja de estilo XSL existente, y puede esperar indefinidamente, pensando que los capítulos tienen problemas para descargarse. Todo lo que puede hacer para leer la documentación es abrir la consola y leer el código fuente en la pestaña Recursos.

Answer 2

Comencé a probar esto y me encontré con el problema local de seguridad de archivos / Chrome. Una solución muy simple es colocar el archivo XML y XSL en, por ejemplo, la carpeta pública de Dropbox y obtener enlaces a ambos archivos. Coloque el enlace a la transformación XSL en el encabezado XML. ¡Usa el enlace XML en Chrome Y FUNCIONA!

Answer 3

Compruebe http://www.aranedabienesraices.com.ar

Este sitio está construido con XML / XSLT del lado del cliente. Funciona en IE6-7-8, FF, O, Safari y Chrome. ¿Estás enviando encabezados HTTP correctamente? ¿Estás respetando la misma política de origen?

Answer 4

El problema basado en Chrome no se trata del espacio de nombres xml que es xmlns="http://www.w3.org/1999/xhtml" . Sin el atributo namespace, tampoco funcionará con IE.

Debido a la restricción de seguridad, debe agregar el --allow-file-access-from-files cuando inicia el cromo. Creo que los usuarios de linux / * nix pueden hacerlo fácilmente a través del terminal, pero para los usuarios de Windows, deben abrir las propiedades del acceso directo de Chrome y agregarlo al destino deseado como se muestra a continuación;

Click derecho -> Propiedades -> Target

Aquí hay una ruta completa de muestra con las banderas que uso en mi máquina;

"C:/Program Files (x86)/Google/Chrome/Application/chrome.exe" --allow-file-access-from-files

Espero que mostrar este paso paso a paso ayude a los usuarios de Windows a resolver el problema, esta es la razón por la que agregué esta publicación.

Answer 5

En el momento de escribir, había un error en Chrome que requería un atributo xmlns para activar la representación:

<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >

Este fue el problema con el que me encontré al servir el archivo xml de un servidor .

Si a diferencia de mí, está viendo el archivo xml desde un file:/// url , entonces las soluciones que mencionan --allow-file-access-from-files son las que desea

Answer 6

Intenté poner el archivo en wwwroot . Por lo tanto, al acceder a la página en Chrome, esta es la dirección localhost / yourpage.xml .

Answer 7

La otra respuesta a continuación por Eric es incorrecta. La declaración del espacio de nombres que mencionó no tuvo nada que ver con el problema.

La razón real por la que no funciona se debe a problemas de seguridad (véase el número 4197 , ejemplar 111905 ).

Imagina este escenario:

1. Recibe un mensaje de correo electrónico de un atacante que contiene una página web como archivo adjunto, que descarga.

2. Abre la página web ahora local en su navegador.

3. La página web local crea un <iframe> cuyo origen es https://mail.google.com/mail/ .

4. Como ha iniciado sesión en Gmail, el marco carga los mensajes en su bandeja de entrada.

5. La página web local lee los contenidos del marco utilizando JavaScript para acceder a los frames[0].document.documentElement.innerHTML . (Una página web en línea no podría realizar este paso porque vendría de un origen que no es de Gmail, la misma política de origen haría que fallara la lectura).

6. La página web local coloca los contenidos de su bandeja de entrada en un <textarea> y envía los datos a través de un formulario POST al servidor web del atacante. Ahora el atacante tiene su bandeja de entrada , que puede ser útil para enviar spam o identificar el robo.

Chrome frustra el escenario anterior poniendo restricciones en los archivos locales que se abren con Chrome. Para superar estas restricciones, tenemos dos soluciones:

1. Intenta ejecutar Chrome con el --allow-file-access-from-files . No lo he probado yo mismo, pero si funciona, su sistema ahora también será vulnerable a los escenarios del tipo mencionado anteriormente.

2. Subirlo a un host, y el problema resuelto.

Answer 8

Lo más cerca que puedo decir, Chrome está buscando el encabezado

Tipo de contenido: texto / xml

Entonces funciona --- otras iteraciones han fallado.

Asegúrese de que su servidor web esté proporcionando esto. También explica por qué falla para file: // URI xml files.

Answer 9

Lo que Eric dice es correcto.

En el xsl, para la etiqueta xsl: stylesheet tienen los siguientes atributos

version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"

Funciona bien en cromo.

Answer 10

Tuve el mismo problema en localhost. Correr por Internet en busca de la respuesta y apruebo que --allow-file-access-from-files agregar --allow-file-access-from-files . Trabajo en Mac, así que para mí tuve que pasar por terminal sudo /Applications/Google/ Chrome.app/Contents/MacOS/Google/ Chrome --allow-file-access-from-files e ingrese su contraseña (si tiene uno).

Otra cosa pequeña: nada funcionará a menos que agregue a su archivo .xml la referencia a su archivo .xsl como sigue <?xml-stylesheet type="text/xsl" href="<path to file>"?> . Otra pequeña cosa de la que no me di cuenta de inmediato: debería abrir su archivo .xml en el navegador, no el .xsl.