2

我已经阅读了几篇关于不同 HTTP 重定向状态代码优点的文档,但这些文档都非常以 SEO 为中心。我现在遇到了一个搜索引擎不考虑的问题,因为相关网站的部分不公开可见。

但是,我们确实希望我们的网站尽可能准确/有用地处理元数据,尤其是出于可访问性的原因。

现在,我们的应用程序获取第三方提供的外部链接,并将它们路由到带有免责声明的反欺骗页面。由于此重定向页面也可以通过 Ajax 调用有效地嵌入某些星座中,因此我们还希望从引用者中剥离任何查询参数(出于隐私目的;目标站点无权查找用户之前访问的内部页面) .

为此,确认按钮会触发一个服务器端脚本,该脚本反过来会重定向(而不仅仅是为用户打开页面)。

至于为什么我们的反欺骗免责声明页面最终会触发重定向。

问题是:

我使用哪个状态码有什么不同吗?非典型浏览器(例如屏幕阅读器)是否在乎?如果是这样,这种重定向的最佳做法是什么?语义上最合理的,如果你愿意的话?在我看来,他们都有不同程度的不真诚。

我正在考虑 302 - 但由于尝试为页面添加书签是没有意义的(它受 crsf 令牌保护),所以 301 也可能没有害处,是吗?所以我想知道是否有理由让我更喜欢一个。

4

1 回答 1

3

唔。这是清单。301 听起来不错(强调我的):

请求的资源已被分配了一个新的永久 URI ,并且任何将来对该资源的引用都应该使用返回的 URI 之一。如果可能,具有链接编辑功能的客户端应该自动将对 Request-URI 的引用重新链接到服务器返回的一个或多个新引用。

302 不符合我的意见:

请求的资源临时驻留在不同的 URI 下

然而,我最喜欢的是303 see other

可以在不同的 URI 下找到对请求的响应,并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。

但这可能非常罕见(我从未见过它在野外使用过),以至于一些客户可能不理解它——这将使您对最大兼容性的渴望变得毫无意义。301可能是最接近的选择。

于 2010-03-17T11:11:43.217 回答