I have an XML document here that is served with a corresponding XSL file. The transformation is left to be executed client-side, without JavaScript.
我这里有一个XML文档,它与相应的XSL文件一起提供。转换留给客户端执行,没有JavaScript。
This works fine in IE (shock horror), but in Google Chrome, just displays the document's text nodes.
这在IE(冲击恐怖)中运行良好,但在谷歌浏览器中,只显示文档的文本节点。
I know that it is possible to do client-side XSL in Chrome, as I have seen examples of it, but I am yet to be able to replicate this success myself
我知道可以在Chrome中进行客户端XSL,因为我已经看过它的例子,但我还是能够自己复制这个成功
What am I doing wrong?
我究竟做错了什么?
10 个解决方案
#1
107
The other answer below by Eric is wrong. The namespace declaration he mentioned had nothing to do with the problem.
埃里克的另一个答案是错误的。他提到的名称空间声明与问题无关。
The real reason it doesn't work is due to security concerns (cf. issue 4197, issue 111905).
它不起作用的真正原因是出于安全考虑(参见问题4197,问题111905)。
Imagine this scenario:
想象一下这种情况:
-
You receive an email message from an attacker containing a web page as an attachment, which you download.
您收到来自攻击者的电子邮件,其中包含您下载的附件网页。
-
You open the now-local web page in your browser.
您可以在浏览器中打开现在本地的网页。
-
The local web page creates an
<iframe>
whose source is https://mail.google.com/mail/.本地网页会创建一个
-
Because you are logged in to Gmail, the frame loads the messages in your inbox.
由于您已登录Gmail,因此框架会在收件箱中加载邮件。
-
The local web page reads the contents of the frame by using JavaScript to access
frames[0].document.documentElement.innerHTML
. (An online web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)本地网页使用JavaScript访问框架[0] .document.documentElement.innerHTML来读取框架的内容。 (在线网页无法执行此步骤,因为它来自非Gmail来源;同源策略会导致读取失败。)
-
The local web page places the contents of your inbox into a
<textarea>
and submits the data via a form POST to the attacker's web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.本地网页将收件箱的内容放入
Chrome foils the above scenario by putting restrictions on local files opened using Chrome. To overcome these restrictions, we've got two solutions:
Chrome通过限制使用Chrome打开的本地文件来阻止上述情况。为了克服这些限制,我们有两个解决方案:
-
Try running Chrome with the
--allow-file-access-from-files
flag. I've not tested this myself, but if it works, your system will now also be vulnerable to scenarios of the kind mentioned above.尝试使用--allow-file-access-from-files标志运行Chrome。我自己没有对此进行过测试,但如果它能够正常工作,那么您的系统现在也容易受到上述类型的影响。
-
Upload it to a host, and problem solved.
将其上传到主机,问题解决了。
#2
15
At the time of writing, there was a bug in chrome which required an xmlns
attribute in order to trigger rendering:
在撰写本文时,chrome中存在一个错误,它需要一个xmlns属性才能触发渲染:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
This was the problem I was running into when serving the xml file from a server.
这是我从服务器提供xml文件时遇到的问题。
If unlike me, you are viewing the xml file from a file:///
url, then the solutions mentioning --allow-file-access-from-files
are the ones you want
如果不像我,你正在从文件:/// url查看xml文件,那么提到--allow-file-access-from-files的解决方案就是你想要的
#3
5
I had the same problem on localhost. Running around the Internet looking for the answer and I approve that adding --allow-file-access-from-files
works. I work on Mac, so for me I had to go through terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files
and enter your password (if you have one).
我在localhost上遇到了同样的问题。在互联网上运行寻找答案,我同意添加--allow-file-access-from-files有效。我在Mac上工作,所以对我来说,我必须通过终端sudo / Applications / Google \ Chrome.app/Contents/MacOS/Google \ Chrome - 从文件访问文件并输入你的密码(如果你有的话)一)。
Another small thing - nothing will work unless you add to your .xml file the reference to your .xsl file as follows <?xml-stylesheet type="text/xsl" href="<path to file>"?>
. Another small thing I didn't realise immediately - you should be opening your .xml file in browser, no the .xsl.
另一个小问题 - 除非你在.xml文件中添加对你的.xsl文件的引用,否则什么都不会起作用,如下所示<?xml-stylesheet type =“text / xsl”href =“
#4
4
The problem based on Chrome is not about the xml namespace which is xmlns="http://www.w3.org/1999/xhtml"
. Without the namesspace attribute, it won't work with IE either.
基于Chrome的问题与xml名称空间无关,即xmlns =“http://www.w3.org/1999/xhtml”。没有namesspace属性,它也不适用于IE。
Because of the security restriction, you have to add the --allow-file-access-from-files
flag when you start the chrome. I think linux/*nix users can do that easily via the terminal but for windows users, you have to open the properties of the Chrome shortcut and add it in the target destination as below;
由于安全限制,您必须在启动chrome时添加--allow-file-access-from-files标志。我认为linux / * nix用户可以通过终端轻松完成,但对于Windows用户,您必须打开Chrome快捷方式的属性并将其添加到目标目标中,如下所示;
Right-Click -> Properties -> Target
右键单击 - >属性 - >目标
Here is a sample full path with the flags which I use on my machine;
这是一个示例完整路径,其中包含我在我的机器上使用的标志;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
I hope showing this step-by-step will help windows users for the problem, this is why I've added this post.
我希望逐步显示这个问题会帮助Windows用户,这就是我添加这篇文章的原因。
#5
3
Well it does not work if the XML file (starting by the standard PI:
好吧,如果XML文件(从标准PI开始:
<?xml-stylesheet type="text/xsl" href="..."?>
for referencing the XSL stylesheet) is served as "application/xml". In that case, Chrome will still download the referenced XSL stylesheet, but nothing will be rendered, as it will silently change the document types from "application/xml" into "Document" (!??) and "text/xsl" into "Stylesheet" (!??), and then will attempt to render the XML document as if it was an HTML(5) document, without running first its XSLT processor. And Nothing at all will be displayed in the screen (whose content will continue to show the previous page from which the XML page was referenced, and will continue spinning the icon, as if the document was never completely loaded.
用于引用XSL样式表)用作“application / xml”。在这种情况下,Chrome仍会下载引用的XSL样式表,但不会呈现任何内容,因为它会将文档类型从“application / xml”静默更改为“Document”(!??)和“text / xsl”到“样式表“(!??),然后将尝试将XML文档呈现为HTML(5)文档,而不首先运行其XSLT处理器。并且屏幕上将不会显示任何内容(其内容将继续显示引用XML页面的上一页,并将继续旋转图标,就好像文档从未完全加载一样。
You can perfectly use the Chrome console, that shows that all resources are loaded, but they are incorrectly interpreted.
您可以完美地使用Chrome控制台,该控制台显示已加载所有资源,但它们被错误地解释。
So yes, Chrome currently only render XML files (with its optional leading XSL stylesheet declaration), only if it is served as "text/xml", but not as "application/xml" as it should for client-side rendered XML with an XSL declaration.
所以,是的,Chrome目前只呈现XML文件(带有可选的领先XSL样式表声明),只有当它作为“text / xml”提供时,而不是作为“application / xml”,因为它应该用于客户端呈现的XML XSL声明。
For XML files served as "text/xml" or "application/xml" and that do not contain an XSL stylesheet declaration, Chrome should still use a default stylesheet to render it as a DOM tree, or at least as its text source. But it does not, and here again it attempts to render it as if it was HTML, and bugs immediately on many scripts (including a default internal one) that attempt to access to "document.body" for handling onLoad events and inject some javascript handler in it.
对于作为“text / xml”或“application / xml”的XML文件,并且不包含XSL样式表声明,Chrome仍应使用默认样式表将其呈现为DOM树,或至少作为其文本源。但它没有,并且再次尝试将其呈现为HTML,并且立即在许多脚本(包括默认内部脚本)上出现错误,这些脚本试图访问“document.body”以处理onLoad事件并注入一些javascript处理程序在里面。
An example of site that does not work as expected (the Common Lisp documentation) in Chrome, but works in IE which supports client-side XSLT:
在Chrome中无法按预期工作的网站示例(Common Lisp文档),但在IE中支持客户端XSLT:
http://common-lisp.net/project/bknr/static/lmman/toc.html
http://common-lisp.net/project/bknr/static/lmman/toc.html
This index page above is displayed correctly, but all links will drive to XML documents with a basic XSL declaration to an existing XSL stylesheet document, and you can wait indefinitely, thinking that the chapters have problems to be downloaded. All you can do to read the docuemntation is to open the console and read the source code in the Resources tab.
上面的索引页面显示正确,但是所有链接都将使用基本XSL声明驱动到现有XSL样式表文档的XML文档,您可以无限期地等待,认为章节有下载问题。您只需打开控制台并阅读“资源”选项卡中的源代码即可阅读文档。
#6
2
As close as I can tell, Chrome is looking for the header
尽我所知,Chrome正在寻找标题
Content-Type: text/xml
内容类型:text / xml
Then it works --- other iterations have failed.
然后它工作---其他迭代失败。
Make sure your web server is providing this. It also explains why it fails for file://URI xml files.
确保您的Web服务器提供此功能。它还解释了为什么它失败了file:// URI xml文件。
#7
1
Check http://www.aranedabienesraices.com.ar
查看http://www.aranedabienesraices.com.ar
This site is built with XML/XSLT client-side. It works on IE6-7-8, FF, O, Safari and Chrome. Are you sending HTTP headers correctly? Are you respecting the same-origin policy?
该站点使用XML / XSLT客户端构建。它适用于IE6-7-8,FF,O,Safari和Chrome。您是否正确发送HTTP标头?您是否尊重同源政策?
#8
0
I tried putting the file in the wwwroot. So when accessing the page in Chrome, this is the address localhost/yourpage.xml.
我尝试将文件放在wwwroot中。因此,当访问Chrome中的页面时,这是地址localhost / yourpage.xml。
#9
0
What Eric says is correct.
埃里克说的是对的。
In the xsl, for the xsl:stylesheet tag have the following attributes
在xsl中,对于xsl:stylesheet标记具有以下属性
version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml"
version =“1.0”xmlns:xsl =“http://www.w3.org/1999/XSL/Transform”xmlns =“http://www.w3.org/1999/xhtml”
It works fine in chrome.
它在铬中工作得很好。
#10
0
I started testing this and ran into the local file / Chrome security issue. A very simple workaround is put the XML and XSL file in, say, Dropbox public folder and get links to both files. Put the link to the XSL transform in the XML head. Use the XML link in Chrome AND IT WORKS!
我开始测试这个并遇到了本地文件/ Chrome安全问题。一个非常简单的解决方法是将XML和XSL文件放在Dropbox公共文件夹中,并获取这两个文件的链接。将链接放在XML头中的XSL转换中。使用Chrome和IT工作中的XML链接!
#1
107
The other answer below by Eric is wrong. The namespace declaration he mentioned had nothing to do with the problem.
埃里克的另一个答案是错误的。他提到的名称空间声明与问题无关。
The real reason it doesn't work is due to security concerns (cf. issue 4197, issue 111905).
它不起作用的真正原因是出于安全考虑(参见问题4197,问题111905)。
Imagine this scenario:
想象一下这种情况:
-
You receive an email message from an attacker containing a web page as an attachment, which you download.
您收到来自攻击者的电子邮件,其中包含您下载的附件网页。
-
You open the now-local web page in your browser.
您可以在浏览器中打开现在本地的网页。
-
The local web page creates an
<iframe>
whose source is https://mail.google.com/mail/.本地网页会创建一个
-
Because you are logged in to Gmail, the frame loads the messages in your inbox.
由于您已登录Gmail,因此框架会在收件箱中加载邮件。
-
The local web page reads the contents of the frame by using JavaScript to access
frames[0].document.documentElement.innerHTML
. (An online web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)本地网页使用JavaScript访问框架[0] .document.documentElement.innerHTML来读取框架的内容。 (在线网页无法执行此步骤,因为它来自非Gmail来源;同源策略会导致读取失败。)
-
The local web page places the contents of your inbox into a
<textarea>
and submits the data via a form POST to the attacker's web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.本地网页将收件箱的内容放入
Chrome foils the above scenario by putting restrictions on local files opened using Chrome. To overcome these restrictions, we've got two solutions:
Chrome通过限制使用Chrome打开的本地文件来阻止上述情况。为了克服这些限制,我们有两个解决方案:
-
Try running Chrome with the
--allow-file-access-from-files
flag. I've not tested this myself, but if it works, your system will now also be vulnerable to scenarios of the kind mentioned above.尝试使用--allow-file-access-from-files标志运行Chrome。我自己没有对此进行过测试,但如果它能够正常工作,那么您的系统现在也容易受到上述类型的影响。
-
Upload it to a host, and problem solved.
将其上传到主机,问题解决了。
#2
15
At the time of writing, there was a bug in chrome which required an xmlns
attribute in order to trigger rendering:
在撰写本文时,chrome中存在一个错误,它需要一个xmlns属性才能触发渲染:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
This was the problem I was running into when serving the xml file from a server.
这是我从服务器提供xml文件时遇到的问题。
If unlike me, you are viewing the xml file from a file:///
url, then the solutions mentioning --allow-file-access-from-files
are the ones you want
如果不像我,你正在从文件:/// url查看xml文件,那么提到--allow-file-access-from-files的解决方案就是你想要的
#3
5
I had the same problem on localhost. Running around the Internet looking for the answer and I approve that adding --allow-file-access-from-files
works. I work on Mac, so for me I had to go through terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files
and enter your password (if you have one).
我在localhost上遇到了同样的问题。在互联网上运行寻找答案,我同意添加--allow-file-access-from-files有效。我在Mac上工作,所以对我来说,我必须通过终端sudo / Applications / Google \ Chrome.app/Contents/MacOS/Google \ Chrome - 从文件访问文件并输入你的密码(如果你有的话)一)。
Another small thing - nothing will work unless you add to your .xml file the reference to your .xsl file as follows <?xml-stylesheet type="text/xsl" href="<path to file>"?>
. Another small thing I didn't realise immediately - you should be opening your .xml file in browser, no the .xsl.
另一个小问题 - 除非你在.xml文件中添加对你的.xsl文件的引用,否则什么都不会起作用,如下所示<?xml-stylesheet type =“text / xsl”href =“
#4
4
The problem based on Chrome is not about the xml namespace which is xmlns="http://www.w3.org/1999/xhtml"
. Without the namesspace attribute, it won't work with IE either.
基于Chrome的问题与xml名称空间无关,即xmlns =“http://www.w3.org/1999/xhtml”。没有namesspace属性,它也不适用于IE。
Because of the security restriction, you have to add the --allow-file-access-from-files
flag when you start the chrome. I think linux/*nix users can do that easily via the terminal but for windows users, you have to open the properties of the Chrome shortcut and add it in the target destination as below;
由于安全限制,您必须在启动chrome时添加--allow-file-access-from-files标志。我认为linux / * nix用户可以通过终端轻松完成,但对于Windows用户,您必须打开Chrome快捷方式的属性并将其添加到目标目标中,如下所示;
Right-Click -> Properties -> Target
右键单击 - >属性 - >目标
Here is a sample full path with the flags which I use on my machine;
这是一个示例完整路径,其中包含我在我的机器上使用的标志;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
I hope showing this step-by-step will help windows users for the problem, this is why I've added this post.
我希望逐步显示这个问题会帮助Windows用户,这就是我添加这篇文章的原因。
#5
3
Well it does not work if the XML file (starting by the standard PI:
好吧,如果XML文件(从标准PI开始:
<?xml-stylesheet type="text/xsl" href="..."?>
for referencing the XSL stylesheet) is served as "application/xml". In that case, Chrome will still download the referenced XSL stylesheet, but nothing will be rendered, as it will silently change the document types from "application/xml" into "Document" (!??) and "text/xsl" into "Stylesheet" (!??), and then will attempt to render the XML document as if it was an HTML(5) document, without running first its XSLT processor. And Nothing at all will be displayed in the screen (whose content will continue to show the previous page from which the XML page was referenced, and will continue spinning the icon, as if the document was never completely loaded.
用于引用XSL样式表)用作“application / xml”。在这种情况下,Chrome仍会下载引用的XSL样式表,但不会呈现任何内容,因为它会将文档类型从“application / xml”静默更改为“Document”(!??)和“text / xsl”到“样式表“(!??),然后将尝试将XML文档呈现为HTML(5)文档,而不首先运行其XSLT处理器。并且屏幕上将不会显示任何内容(其内容将继续显示引用XML页面的上一页,并将继续旋转图标,就好像文档从未完全加载一样。
You can perfectly use the Chrome console, that shows that all resources are loaded, but they are incorrectly interpreted.
您可以完美地使用Chrome控制台,该控制台显示已加载所有资源,但它们被错误地解释。
So yes, Chrome currently only render XML files (with its optional leading XSL stylesheet declaration), only if it is served as "text/xml", but not as "application/xml" as it should for client-side rendered XML with an XSL declaration.
所以,是的,Chrome目前只呈现XML文件(带有可选的领先XSL样式表声明),只有当它作为“text / xml”提供时,而不是作为“application / xml”,因为它应该用于客户端呈现的XML XSL声明。
For XML files served as "text/xml" or "application/xml" and that do not contain an XSL stylesheet declaration, Chrome should still use a default stylesheet to render it as a DOM tree, or at least as its text source. But it does not, and here again it attempts to render it as if it was HTML, and bugs immediately on many scripts (including a default internal one) that attempt to access to "document.body" for handling onLoad events and inject some javascript handler in it.
对于作为“text / xml”或“application / xml”的XML文件,并且不包含XSL样式表声明,Chrome仍应使用默认样式表将其呈现为DOM树,或至少作为其文本源。但它没有,并且再次尝试将其呈现为HTML,并且立即在许多脚本(包括默认内部脚本)上出现错误,这些脚本试图访问“document.body”以处理onLoad事件并注入一些javascript处理程序在里面。
An example of site that does not work as expected (the Common Lisp documentation) in Chrome, but works in IE which supports client-side XSLT:
在Chrome中无法按预期工作的网站示例(Common Lisp文档),但在IE中支持客户端XSLT:
http://common-lisp.net/project/bknr/static/lmman/toc.html
http://common-lisp.net/project/bknr/static/lmman/toc.html
This index page above is displayed correctly, but all links will drive to XML documents with a basic XSL declaration to an existing XSL stylesheet document, and you can wait indefinitely, thinking that the chapters have problems to be downloaded. All you can do to read the docuemntation is to open the console and read the source code in the Resources tab.
上面的索引页面显示正确,但是所有链接都将使用基本XSL声明驱动到现有XSL样式表文档的XML文档,您可以无限期地等待,认为章节有下载问题。您只需打开控制台并阅读“资源”选项卡中的源代码即可阅读文档。
#6
2
As close as I can tell, Chrome is looking for the header
尽我所知,Chrome正在寻找标题
Content-Type: text/xml
内容类型:text / xml
Then it works --- other iterations have failed.
然后它工作---其他迭代失败。
Make sure your web server is providing this. It also explains why it fails for file://URI xml files.
确保您的Web服务器提供此功能。它还解释了为什么它失败了file:// URI xml文件。
#7
1
Check http://www.aranedabienesraices.com.ar
查看http://www.aranedabienesraices.com.ar
This site is built with XML/XSLT client-side. It works on IE6-7-8, FF, O, Safari and Chrome. Are you sending HTTP headers correctly? Are you respecting the same-origin policy?
该站点使用XML / XSLT客户端构建。它适用于IE6-7-8,FF,O,Safari和Chrome。您是否正确发送HTTP标头?您是否尊重同源政策?
#8
0
I tried putting the file in the wwwroot. So when accessing the page in Chrome, this is the address localhost/yourpage.xml.
我尝试将文件放在wwwroot中。因此,当访问Chrome中的页面时,这是地址localhost / yourpage.xml。
#9
0
What Eric says is correct.
埃里克说的是对的。
In the xsl, for the xsl:stylesheet tag have the following attributes
在xsl中,对于xsl:stylesheet标记具有以下属性
version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml"
version =“1.0”xmlns:xsl =“http://www.w3.org/1999/XSL/Transform”xmlns =“http://www.w3.org/1999/xhtml”
It works fine in chrome.
它在铬中工作得很好。
#10
0
I started testing this and ran into the local file / Chrome security issue. A very simple workaround is put the XML and XSL file in, say, Dropbox public folder and get links to both files. Put the link to the XSL transform in the XML head. Use the XML link in Chrome AND IT WORKS!
我开始测试这个并遇到了本地文件/ Chrome安全问题。一个非常简单的解决方法是将XML和XSL文件放在Dropbox公共文件夹中,并获取这两个文件的链接。将链接放在XML头中的XSL转换中。使用Chrome和IT工作中的XML链接!