J'ai un document XML ici qui est servi avec un correspondant fichier XSL . La transformation doit être exécutée côté client, sans JavaScript.
Cela fonctionne bien dans IE (horreur de choc), mais dans Google Chrome, affiche simplement les nœuds de texte du document.
Je sais qu'il est possible de faire du XSL côté client dans Chrome, comme j'en ai vu des exemples, mais je ne suis pas encore en mesure de reproduire ce succès moi-même
Qu'est-ce que je fais mal?
Réponses:
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 cela ne fonctionne pas est dû à des problèmes de sécurité (cf. numéro 4197 , numéro 111905 ).
Imaginez ce scénario:
Vous recevez un e-mail d'un attaquant contenant une page Web en pièce jointe, que vous téléchargez.
Vous ouvrez la page Web désormais locale dans votre navigateur.
La page Web locale crée une <iframe>source dont la source est https://mail.google.com/mail/ .
Comme vous êtes connecté à Gmail, le cadre charge les messages dans votre boîte de réception.
La page Web locale lit le contenu du cadre en utilisant JavaScript pour y accéder frames[0].document.documentElement.innerHTML. (Une page Web en ligne ne pourrait pas effectuer cette étape car elle proviendrait d'une origine non Gmail; la politique de même origine entraînerait l'échec de la lecture.)
La page Web locale place le contenu de votre boîte de réception dans un <textarea>et soumet les données via un formulaire POST au serveur Web de l'attaquant. L'attaquant a maintenant votre boîte de réception , ce qui peut être utile pour le spam ou le vol d'identité.
Chrome déjoue le scénario ci-dessus en imposant des restrictions sur les fichiers locaux ouverts à l'aide de Chrome. Pour surmonter ces restrictions, nous avons deux solutions:
Essayez d'exécuter Chrome avec l' --allow-file-access-from-files indicateur. 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.
Téléchargez-le sur un hôte et le problème est résolu.
--allow-file-access-from-filesmarche bien.
Au moment de la rédaction de cet article, il y avait un bogue dans chrome qui nécessitait un xmlnsattribut pour déclencher le rendu:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
C'était le problème que je rencontrais lors de la diffusion du fichier xml à partir d'un serveur .
Si contrairement à moi, vous visualisez le fichier xml depuis une file:///URL , alors les solutions mentionnées --allow-file-access-from-filessont celles que vous souhaitez
Le problème basé sur Chrome ne concerne pas l' espace de noms xml qui l'est xmlns="http://www.w3.org/1999/xhtml". Sans l'attribut namesspace, cela ne fonctionnera pas non plus avec IE.
En raison de la restriction de sécurité, vous devez ajouter l' --allow-file-access-from-filesindicateur lorsque vous démarrez le chrome. Je pense que les utilisateurs de linux / * nix peuvent le faire facilement via le terminal, mais pour les utilisateurs de Windows, vous devez ouvrir les propriétés du raccourci Chrome et l'ajouter dans la destination cible comme ci-dessous;
Clic droit -> Propriétés -> Cible
Voici un exemple de chemin complet avec les indicateurs que j'utilise sur ma machine;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
J'espère que montrer cette étape par étape aidera les utilisateurs de Windows à résoudre le problème, c'est pourquoi j'ai ajouté ce message.
J'ai eu le même problème sur localhost. Courir sur Internet à la recherche de la réponse et j'approuve que l'ajout --allow-file-access-from-filesfonctionne. 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-fileset entrer votre mot de passe (si vous en avez un).
Une autre petite chose - rien ne fonctionnera à moins que vous ajoutiez à 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.
Eh bien cela ne fonctionne pas si le fichier XML (en commençant par le PI standard:
<?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 documents de "application / xml" en "Document" (! ??) et "texte / 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 à afficher 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 Chrome, qui montre que toutes les ressources sont chargées, mais elles sont mal interprétées.
Donc oui, Chrome n'affiche actuellement que les fichiers XML (avec sa déclaration de feuille de style XSL facultative), uniquement s'il est servi en tant que "text / xml", mais pas en tant que "application / xml" comme il le devrait pour le XML rendu côté client avec un Déclaration XSL.
Pour les fichiers XML servis en tant que "text / xml" ou "application / xml" et qui ne contiennent pas de déclaration de feuille de style XSL, Chrome doit toujours utiliser une feuille de style par défaut pour le rendre sous forme d'arborescence DOM, ou du moins comme source de texte. Mais ce n'est pas le cas, et là encore, il tente de le rendre comme s'il s'agissait de HTML, et bogue immédiatement sur de nombreux scripts (y compris un interne par défaut) qui tentent d'accéder à "document.body" pour gérer les événements onLoad et injecter du javascript gestionnaire dedans.
Un exemple de site qui ne fonctionne pas comme prévu (la documentation Common Lisp) dans Chrome, mais qui fonctionne dans IE qui prend en charge XSLT côté client:
http://common-lisp.net/project/bknr/static/lmman/toc.html
Cette page d'index ci-dessus s'affiche correctement, mais tous les liens conduiront à 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 à télécharger. Tout ce que vous pouvez faire pour lire la documentation est d'ouvrir la console et de lire le code source dans l'onglet Ressources.
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 de la même origine?
xmlnsattribut.
Ce que dit Eric est correct.
Dans le xsl, pour la balise xsl: stylesheet ont les attributs suivants
version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"
Cela fonctionne très bien en chrome.
J'ai commencé à tester cela et j'ai rencontré le problème de sécurité du fichier local / Chrome. Une solution de contournement très simple consiste à placer le fichier XML et XSL dans, par exemple, le dossier public Dropbox et à obtenir des liens vers les deux fichiers. Placez le lien vers la transformation XSL dans l'en-tête XML. Utilisez le lien XML dans Chrome ET CELA FONCTIONNE!
Après 8 ans, la situation a un peu changé.
Je ne parviens pas à ouvrir une nouvelle session de Google Chrome sans autres paramètres et à autoriser le schéma «fichier:».
Sur macOS, je fais:
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
Sans ces arguments, je ne peux pas tester la feuille de style XSL en local.