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

88

Tengo un documento XML aquí que se sirve con un archivo XSL correspondiente . Se deja que la transformación se ejecute en el lado del cliente, sin JavaScript.

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

Sé que es posible hacer XSL del lado del cliente en Chrome, ya que he visto ejemplos, pero todavía no puedo replicar este éxito por mí mismo.

¿Qué estoy haciendo mal?

Eric
fuente
Sería genial publicar la solución, cuando la sepa. Realmente no he usado Chrome para nada serio, me parece un juguete de Google. ¿Por qué necesita realizar XSLT en el lado del cliente?
Dimitre Novatchev
Yo no. Pensé que sería un poco genial. Y todavía me gustaría saber por qué algunas cosas funcionan en Chrome, pero la mía no. Ah, y para los usuarios de IE, perdón por el atroz estilo arcoíris de la página.
Eric
12
Para mí, Chrome puede hacer la transformación solo cuando abre el XML sobre http: //, no funciona cuando se trabaja a través de file: //, el atributo xmlns no hace ninguna diferencia para mí.
Jaroslav Záruba
Este error se menciona aquí
Flavio Cysne
1
El error de Chrome real para esto está en code.google.com/p/chromium/issues/detail?id=111905
Grant Peters

Respuestas:

116

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

La verdadera razón por la que no funciona es debido a problemas de seguridad ( consulte el número 4197 , el número 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 una <iframe>cuya fuente es https://mail.google.com/mail/ .

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

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

  6. La página web local coloca el contenido de su bandeja de entrada en un <textarea>correo electrónico 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 robo de identidad.

Chrome frustra el escenario anterior al imponer restricciones a los archivos locales abiertos con Chrome. Para superar estas restricciones, tenemos dos soluciones:

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

  2. Súbelo a un host y problema resuelto.

Pacerier
fuente
2
Esto es cierto, sin embargo, esa no fue la única causa del problema. He estado siguiendo el informe de "error" por un tiempo. Sin embargo, tampoco pude hacer que funcione en el lado del servidor sin el xmlnsatributo. Es posible que esto haya cambiado en versiones más recientes de Chrome.
Eric
4
@Eric ok, esto puede no ser una respuesta a tu problema, pero es la respuesta correcta a tu pregunta. a juzgar por los comentarios de los visitantes de esta página, podemos ver que la respuesta que había sido marcada como respuesta no está resolviendo sus problemas. (de lo contrario, ¿por qué tendrían que revisar las otras 6 respuestas para encontrar una solución)?
Pacerier
4
@Pacerier: No es la respuesta correcta a mi pregunta. Mi pregunta era sobre por qué un par de documentos alojados en mi servidor no se estaban transformando correctamente. El problema de seguridad, aunque vale la pena conocerlo, no es relevante para esta pregunta en particular.
Eric
1
@Pacerier Gracias, --allow-file-access-from-filesfunciona bien.
Ibn Saeed
¿Cómo configurar esto en macOS?
Pardeep Jain
14

En el momento de escribir este artículo, había un error en Chrome que requería un xmlnsatributo para activar el renderizado:

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

Este era el problema con el que me encontraba al servir el archivo xml desde un servidor .


Si, a diferencia de mí, está viendo el archivo xml desde una file:///URL , entonces las soluciones mencionadas --allow-file-access-from-filesson las que desea.

Eric
fuente
2
¡Buen descubrimiento! Se llenó un error para esto.
Mohamed Mansour
1
@Peter: depende de tu documento de entrada. La especificación XSLT es bastante clara aquí e IE es demasiado indulgente. Si la entrada es XHTML válido, tiene una declaración de espacio de nombres. Para que XSLT ubique algo en ese documento de entrada, debe definir el espacio de nombres. Sin embargo, no es necesario utilizar el espacio de nombres predeterminado (pero es más fácil).
Abel
10
@Eric: mira mi respuesta, no te ofendas, pero tu respuesta es incorrecta.
Pacerier
4
Esta no es la respuesta (ni la solución, y el "..." es definitivamente un poco vago), Pacerier es la correcta.
RedGlyph
Esto es incorrecto. No requiere esa desaceleración. Está pidiendo números de versión.
UDID
7

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 de espacio de nombres, tampoco funcionará con IE.

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

Clic derecho -> Propiedades -> Destino

ingrese la descripción de la imagen aquí

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 a paso ayude a los usuarios de Windows con el problema, es por eso que agregué esta publicación.

Levent Divilioglu
fuente
6

Tuve el mismo problema en localhost. Corriendo por Internet buscando la respuesta y apruebo que agregar --allow-file-access-from-filesfunciona. Trabajo en Mac, así que para mí tuve que pasar por la terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filese ingresar su contraseña (si tiene una).

Otra pequeña cosa: nada funcionará a menos que agregue a su archivo .xml la referencia a su archivo .xsl de la siguiente manera <?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.

Setrino
fuente
4

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 estilo XSL) se sirve como "application / xml". En ese caso, Chrome seguirá descargando la hoja de estilo XSL a la que se hace referencia, pero no se procesará nada, ya que cambiará silenciosamente los tipos de documentos de "application / xml" a "Document" (! ??) y "text / xsl" into " Stylesheet "(! ??), y luego intentará representar el documento XML como si fuera un documento HTML (5), sin ejecutar primero su procesador XSLT. Y no se mostrará nada en la pantalla (cuyo contenido seguirá mostrando la página anterior desde la que se hizo referencia a la página XML, y seguirá girando el icono, como si el documento nunca se hubiera cargado completamente.

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

Así que sí, Chrome actualmente solo procesa 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 XML representado 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 debe seguir usando una hoja de estilo predeterminada para representarla como un árbol DOM, o al menos como su fuente de texto. Pero no es así, y aquí nuevamente intenta representarlo como si fuera HTML, y falla inmediatamente en muchos scripts (incluido uno interno predeterminado) que intentan acceder a "document.body" para manejar eventos onLoad e inyectar algo de javascript manejador en él.

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 anterior 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.

verdy_p
fuente
3

Por lo 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 lo proporcione. También explica por qué falla para los archivos xml file: // URI.

Juan
fuente
2

Consulte 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á enviando los encabezados HTTP correctamente? ¿Está respetando la política del mismo origen?


fuente
Mira mi respuesta , lo he resuelto. Chrome parece requerir un xmlnsatributo.
Eric
4
No lo creo. Para realizar la transformación, Chrome no necesita establecer el espacio de nombres predeterminado en el espacio de nombres XHTML. Para renderizar XHTML se necesita el XHTML adecuado, por supuesto. Estás mezclando cosas.
El sitio al que se hace referencia anteriormente no está construido con XML sino con XHTML. Los dos no son exactamente iguales (ambos son XML, pero uno también es HTML y el otro no).
jerseyboy
1

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

MiddleKay
fuente
1

Lo que dice Eric es correcto.

En el xsl, para el xsl: la etiqueta de la hoja de estilo tiene los siguientes atributos

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

Funciona bien en cromo.

P Subramanian
fuente
1

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

Mark Whitener
fuente
1

Después de 8 años, la situación cambia un poco.

No puedo abrir una nueva sesión de Google Chrome sin otros parámetros y permitir el esquema 'archivo:'.

En macOS hago:

open -n -a "Google Chrome" --args \
    --disable-web-security \               # This disable all CORS and other security checks
    --user-data-dir=$HOME/fakeChromeDir    # This let you to force open a new Google Chrome session

Sin estos argumentos, no puedo probar la hoja de estilo XSL en local.

Matteo Gaggiano
fuente