从最近开始,我的一些新网页(XHTML 1.1)被设置为执行请求标头的正则表达式,Accept并在用户代理接受XML(Firefox和Safari do)时发送正确的HTTP响应标头.
IE(或任何其他不接受它的浏览器)只会获得普通text/html内容类型.
谷歌机器人(或任何其他搜索机器人)会有这个问题吗？我看过的方法有什么负面影响吗？你认为这个标头嗅探器会对性能有多大影响吗？
内容协商(以及向不同的用户代理提供不同的内容/标题)的一个问题是代理服务器.考虑以下因素; 我在Netscape 4天遇到了这个问题,从那以后一直羞于服务器端的嗅探.
用户A使用Firefox下载您的页面,并获取XHTML/XML Content-Type.用户的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. 错误配置的代理仍然可能不正确地缓存页面和标题,让您失去运气.
唯一真正的问题是,如果您的页面包含无效代码,浏览器将显示xml解析错误,而在text/html中,它们至少会显示可查看的内容.
发送xml没有任何好处,除非你想嵌入svg或正在对页面进行xml处理.
我使用内容协商来切换application/xhtml+xml,text/html就像你描述的那样,没有注意到搜索机器人的任何问题.但是,严格来说,您应该考虑accept头中的q值,该值表示用户代理对每种内容类型的偏好.如果用户代理更喜欢接受text/html但会接受application/xhtml+xml作为备用,那么为了最大的安全性,您应该将该页面作为备用text/html.
京公网安备 11010802040832号 | 京ICP备19059560号-6 