Comment faire pour que XSLT fonctionne dans chrome ?

Question

J'ai un document XML ici qui est servi avec un Fichier XSL . La transformation est laissée pour être exécutée côté client, sans JavaScript.

Cela fonctionne bien dans IE (horreur), mais dans Google Chrome, cela n'affiche que les nœuds de texte du document.

Je sais qu'il est possible de faire du XSL côté client dans Chrome, car j'en ai vu des exemples, mais je ne suis pas encore parvenu à reproduire ce succès moi-même.

Qu'est-ce que je fais de mal ?

Answer 1

L'autre réponse ci-dessous par Eric est fausse. La déclaration d'espace de noms qu'il a mentionnée n'a rien à voir avec le problème.

La vraie raison pour laquelle ça ne marche pas est pour des raisons de sécurité (cf. numéro 4197 , numéro 111905 ).

Imaginez ce scénario :

1. Vous recevez un message électronique d'un attaquant contenant une page Web en pièce jointe, que vous téléchargez.

2. Vous ouvrez la page web désormais locale dans votre navigateur.

3. La page web locale crée un <iframe> dont la source est https://mail.google.com/mail/ .

4. Comme vous êtes connecté à Gmail, le cadre charge les messages de votre boîte de réception.

5. La page web locale lit le contenu de la trame en utilisant JavaScript pour accéder aux éléments suivants frames[0].document.documentElement.innerHTML . (Une page Web en ligne ne serait pas en mesure d'effectuer cette étape car elle proviendrait d'une origine autre que Gmail ; la politique du même origine ferait échouer la lecture).

6. La page web locale place le contenu de votre boîte de réception dans une <textarea> et soumet les données via un formulaire POST au serveur web de l'attaquant. Maintenant, l'attaquant a votre boîte de réception qui peut être utile pour le spamming ou l'usurpation d'identité.

Chrome déjoue le scénario ci-dessus en mettre des restrictions sur les fichiers locaux ouvert avec Chrome. Pour surmonter ces restrictions, nous avons deux solutions :

1. Essayez d'exécuter Chrome avec l'option --allow-file-access-from-files le drapeau. Je ne l'ai pas testé moi-même, mais si cela fonctionne, votre système sera désormais également vulnérable aux scénarios du type mentionné ci-dessus.

2. Téléchargez-le sur un hôte, et le problème est résolu.

Answer 2

Ooh, c'est résolu !

Vous devez disposer d'une déclaration d'espace de noms XHTML :

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

Pourquoi cela n'est-il mentionné nulle part sur Internet ?

Answer 3

J'ai eu le même problème sur localhost. J'ai parcouru l'Internet à la recherche de la réponse et j'approuve que l'ajout de --allow-file-access-from-files fonctionne. Je travaille sur Mac, donc pour moi j'ai dû passer par le terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files et saisissez votre mot de passe (si vous en avez un).

Autre petite chose - rien ne fonctionnera si vous n'ajoutez pas à votre fichier .xml la référence à votre fichier .xsl comme suit <?xml-stylesheet type="text/xsl" href="<path to file>"?> . Une autre petite chose que je n'ai pas réalisé immédiatement - vous devriez ouvrir votre fichier .xml dans le navigateur, pas le .xsl.

Answer 4

Eh bien, cela ne fonctionne pas si le fichier XML (qui commence par la norme PI :

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

pour référencer la feuille de style XSL) est servi comme "application/xml". Dans ce cas, Chrome téléchargera toujours la feuille de style XSL référencée, mais rien ne sera rendu, car il changera silencieusement les types de document de "application/xml" en "Document" ( !??) et "text/xsl" en "Feuille de style" ( !??), puis tentera de rendre le document XML comme s'il s'agissait d'un document HTML(5), sans exécuter d'abord son processeur XSLT. Et rien du tout ne sera affiché à l'écran (dont le contenu continuera à montrer la page précédente à partir de laquelle la page XML a été référencée, et continuera à faire tourner l'icône, comme si le document n'avait jamais été complètement chargé.

Vous pouvez parfaitement utiliser la console de Chrome, qui montre que toutes les ressources sont chargées, mais elles sont mal interprétées.

Donc oui, Chrome ne rend actuellement les fichiers XML (avec sa déclaration de feuille de style XSL optionnelle) que s'ils sont servis en tant que "text/xml", mais pas en tant qu'"application/xml" comme il devrait le faire pour un XML rendu côté client avec une déclaration XSL.

Pour les fichiers XML servis comme "text/xml" ou "application/xml" et qui ne contiennent pas de déclaration de feuille de style XSL, Chrome devrait tout de même utiliser une feuille de style par défaut pour le rendre comme un arbre DOM, ou au moins comme sa source textuelle. Mais il ne le fait pas, et là encore, il tente de le rendre comme s'il s'agissait de HTML, et bute immédiatement sur de nombreux scripts (y compris un script interne par défaut) qui tentent d'accéder à "document.body" pour gérer les événements onLoad et y injecter un gestionnaire javascript.

Un exemple de site qui ne fonctionne pas comme prévu (la documentation Common Lisp) dans Chrome, mais qui fonctionne dans IE qui supporte le XSLT côté client :

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

La page d'index ci-dessus s'affiche correctement, mais tous les liens conduisent à des documents XML avec une déclaration XSL de base vers un document de feuille de style XSL existant, et vous pouvez attendre indéfiniment, pensant que les chapitres ont des problèmes à être téléchargés. Tout ce que vous pouvez faire pour lire la docuemntation est d'ouvrir la console et de lire le code source dans l'onglet Ressources.

Answer 5

Vérifiez http://www.aranedabienesraices.com.ar

Ce site est construit avec XML/XSLT côté client. Il fonctionne sur IE6-7-8, FF, O, Safari et Chrome. Envoyez vous correctement les en-têtes HTTP ? Respectez-vous la politique du same-origin ?