从最近开始，我的一些新网页（XHTML 1.1）被设置为执行请求标头Accept的正则表达式，并在用户代理接受XML时发送正确的HTTP响应标头（Firefox和Safari会这样做）
IE（或任何其他不接受它的浏览器）只会获得普通的text/html内容类型。
Google bot（或任何其他搜索机器人）是否会遇到任何问题？我看过的方法有什么负面影响吗？你认为这个标题嗅探器会对性能有多大影响吗？
答案 0 :(得分：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文章所述。我还假设代理服务器在自动检测这些事情方面有点聪明。
这里是CF that is HTML/XHTML开始进入的地方。当您使用内容协商将application / xhtml + xml提供给一组用户代理，将text / html提供给另一组用户代理时，您就是依靠服务器和用户之间的所有代理来表现良好。
即使世界上所有代理服务器都足够智能识别Vary标头（它们不是），您仍然需要与世界上的计算机管理员竞争。世界上有许多聪明，才华横溢，敬业的IT专业人士。还有更多不那么聪明的人花时间双击安装程序应用程序，并认为“互联网”是菜单中的蓝色E.错误配置的代理仍然可能不正确地缓存页面和标题，让您不幸。
答案 1 :(得分：6)
唯一真正的问题是，如果您的页面包含无效代码，浏览器将显示xml解析错误，而在text / html中，它们至少会显示可查看的内容。
发送xml没有任何好处，除非你想嵌入svg或正在对页面进行xml处理。
答案 2 :(得分：5)
我使用内容协商在application/xhtml+xml和text/html之间切换，就像您描述的那样，但没有注意到搜索机器人的任何问题。但是，严格来说，您应该考虑accept头中的q值，该值表示用户代理对每种内容类型的偏好。如果用户代理更愿意接受text/html但会接受application/xhtml+xml作为替代，那么为了最大的安全性，您应该将该页面作为text/html投放。
答案 3 :(得分：2)
问题是您需要将标记限制为HTML和XHTML的子集。
<script/>未关闭到text/html解析器并将文档杀死下一个</script>）。text/html模式（可能使用前一点中提到的仅XML功能，可能会添加标记名前缀（PHP DOM有时会<default:h1>）。{ {1}}是HTML中的CDATA，但XML序列化程序可能会输出<script>）。<script>if (a && b)</script>或&中的单个未转义href将完全打破XML，并使您的网站仅在IE中工作！）我测试了我的纯XML网站的索引。虽然我使用了<br> MIME类型，但它已被编入索引，但它似乎仍然被解析为HTML（Google没有索引application/xml部分中的文字）。
答案 4 :(得分：1)
由于IE不支持xhtml作为application / xhtml + xml，因此获得跨浏览器支持的唯一方法是使用内容协商。根据{{3}}，内容协商很难，因为滥用通配符，Web浏览器声称支持现有的每种类型的内容！ Safari和Konquer支持xhtml，但只是通过通配符暗示这种支持，而IE不支持它，但也意味着支持。
HTTP Accept标头中的W3C Web Devout，忽略那些没有明确声明支持的浏览器。但请注意，标头并不总是可靠的，并且已知会导致缓存问题。即使你可以使这个工作，不得不维持两个相似但不同的版本将是一个痛苦。
考虑到所有这些问题，当然，当你的工具和图书馆出现时，我赞成让xhtml错过。