16

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

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

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

4

5 回答 5

12

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

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

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

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

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

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

于 2008-12-09T05:55:31.127 回答
6

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

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

于 2008-12-09T01:57:09.843 回答
5

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

于 2008-12-09T00:21:34.263 回答
2

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

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

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

于 2009-01-05T15:52:21.547 回答
1

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

W3C建议仅将 xhtml 发送到在 HTTP Accept 标头中明确声明支持的浏览器，而忽略那些未明确声明支持的浏览器。但请注意，标头并不总是可靠的，并且已知会导致缓存问题。即使你能让这个工作，必须维护两个相似但不同的版本也会很痛苦。

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

于 2010-07-06T00:50:44.653 回答