与 Content: application/xhtml+xml 服务页面相关的问题是什么答案

【问题标题】：What are the problems associated with serving pages with Content: application/xhtml+xml与 Content: application/xhtml+xml 服务页面相关的问题是什么
【发布时间】：2010-09-25 23:14:06
【问题描述】：

从最近开始，我的一些新网页 (XHTML 1.1) 设置为对请求标头 Accept 进行正则表达式，并在用户代理接受 XML 时发送正确的 HTTP 响应标头（Firefox 和 Safari 可以）。

IE（或任何其他不接受它的浏览器）只会得到普通的text/html 内容类型。

Google 机器人（或任何其他搜索机器人）会对此有任何问题吗？我看过的方法有什么负面影响吗？您认为这个标头嗅探器会对性能产生很大影响吗？

【问题讨论】：

标签： xhtml http-headers

【解决方案1】：

内容协商（以及为不同的用户代理提供不同的内容/标头）的一个问题是代理服务器。考虑以下；我在 Netscape 的 4 天里遇到了这个问题，从那时起我就一直害怕服务器端嗅探。

用户 A 使用 Firefox 下载您的页面，并获得 XHTML/XML 内容类型。用户的 ISP 在用户和您的站点之间有一个代理服务器，所以这个页面现在被缓存了。

用户 B（同一个 ISP）使用 Internet Explorer 请求您的页面。请求首先到达代理，代理说“嘿，我有那个页面，在这里；作为 application/xhtml+xml”。提示用户 B 下载文件（因为 IE 将下载以 application/xhtml+xml 形式发送的任何内容。

您可以使用Vary Header 解决此特定问题，如456 Berea Street 文章中所述。我还假设代理服务器在自动检测这些事情方面变得更聪明了。

这就是CF that is HTML/XHTML 开始蔓延的地方。当您使用内容协商将 application/xhtml+xml 提供给一组用户代理，并将 text/html 提供给另一组用户代理时，您依赖的是你的服务器和你的用户之间的所有代理都表现得很好。

即使世界上所有的代理服务器都足够聪明，可以识别 Vary 标头（它们不是），您仍然必须与世界上的计算机管理员抗衡。世界上有很多聪明、有才华和敬业的 IT 专业人员。有更多不那么聪明的人会花时间双击安装程序应用程序并认为“互联网”是他们菜单中的蓝色 E。错误配置的代理仍然可能不正确地缓存页面和标题，让您不走运。

【讨论】：

有趣的艾伦。我会考虑这个。也许我会送他们标签汤。
另外，Vary: 标头会在所有主流浏览器中禁用资源缓存（它们不支持缓存多个版本，因此它们可以安全使用，不缓存任何版本）。

【解决方案2】：

唯一真正的问题是，如果您的页面包含无效代码，浏览器将显示 xml 解析错误，而在 text/html 中，它们至少会显示可查看的内容。

除非您想嵌入 svg 或正在对页面进行 xml 处理，否则发送 xml 并没有任何好处。

【讨论】：

有人可能会问，如果您正在（希望）有意识地决定将您的网页作为 XHTML 提供服务，那么您为什么不也努力确定您的网页是 XHTML 有效的吗？（使用 XML/XHTML 编辑器和验证器是完成此任务的宝贵工具。）

【解决方案3】：

就像您描述的那样，我使用内容协商在 application/xhtml+xml 和 text/html 之间切换，而没有注意到搜索机器人有任何问题。但严格来说，您应该考虑接受标头中的 q 值，该值指示用户代理对每种内容类型的偏好。如果用户代理更愿意接受text/html，但会接受application/xhtml+xml 作为替代，那么为了最大程度的安全，您应该将页面设置为text/html。

【讨论】：

【解决方案4】：

问题是您需要将标记限制为 HTML 和 XHTML 的子集。

你不能使用 XHTML 特性（命名空间，所有元素的自闭合语法），因为它们会破坏 HTML（例如，<script/> 对 text/html 解析器是不封闭的，并且会杀死文档直到下一个 </script> )。
您不能使用 XML 序列化程序，因为它可能会破坏 text/html 模式（可能使用前面提到的仅限 XML 的功能，可能会添加标记名前缀（PHP DOM 有时会使用 <default:h1>）。<script> 是 CDATA在 HTML 中，但 XML 序列化程序可能会输出 <script>if (a &amp;&amp; b)</script>)。
您不能使用 HTML 的紧凑语法（隐含标记、可选引号），因为它不会解析为 XML。
使用 HTML 工具（包括大多数模板引擎）是有风险的，因为它们不关心格式是否正确（href 或 <br> 中的单个未转义的 & 将完全破坏 XML，并使您的网站似乎只能在 IE 中运行！)

我已经测试了我的纯 XML 网站的索引。即使我使用了application/xml MIME 类型，它也已被编入索引，但无论如何它似乎被解析为 HTML（Google 没有将 <[CDATA[ ]]> 部分中的文本编入索引）。

【讨论】：

XML序列化将如何打破文本html模式？我假设您指的是输出，而不是输入？

【解决方案5】：

由于 IE 不支持 xhtml 作为 application/xhtml+xml，因此获得跨浏览器支持的唯一方法是使用内容协商。根据Web Devout 的说法，由于滥用通配符，内容协商很困难，其中网络浏览器声称支持现有的每种类型的内容！ Safari 和 Konquer 支持 xhtml，但只是通过通配符表示支持，而 IE 不支持，但也表示支持。

HTTP Accept 标头中的 W3C recommends only sending xhtml to browsers that specifically declare support 并忽略那些未明确声明支持的浏览器。但请注意，标头并不总是可靠的，并且已知会导致缓存问题。即使您可以使这项工作正常进行，也必须维护两个相似但不同的版本。

考虑到所有这些问题，我赞成放弃 xhtml，当然，当您的工具和库允许时。

【讨论】：