什么HTTP响应状态代码用于随机机会的无关重定向?

cli*_*ait -2 redirect http http-status-codes http-redirect server

我的网站有1%的随机机会将访问者重定向到此YouTube视频.

服务器当前发送旧的302,但我希望它具有更好的语义.

我不知道重定向是永久的还是临时的.从某种意义上说,它是永久性的,人们总是有1%的机会被重定向,而且这是暂时的,因为人们不会每次都被重定向.

当前的3xx响应状态代码都不符合我网站的行为.

HTTP 3xx重定向(来源:维基百科)

301永久移动
此以及将来的所有请求都应该指向给定的URI.[21]

"这和所有未来的要求" - 不,不是所有未来的要求.

302 Found(以前"暂时移动")
告诉客户查看(浏览)另一个URL.302已被303和307取代.这是与该标准相矛盾的行业惯例的一个例子.HTTP/1.0规范(RFC 1945)要求客户端执行临时重定向(原始描述短语是"暂时移动"),[22]但是流行的浏览器实现302具有303 See Other的功能.因此,HTTP/1.1添加了状态代码303和307来区分这两种行为.[23] 但是,一些Web应用程序和框架使用302状态代码,就像它是303一样.[24]

这令人困惑.它确实说,"302已经被303和307取代了",所以我想这已经过时但仍然常用?

303请参阅其他(自HTTP/1.1起)
可以使用GET方法在另一个URI下找到对请求的响应.当收到POST(或PUT/DELETE)时,客户端应该假设服务器已经收到数据,并且应该向给定的URI发出新的GET请求.[25]

"可以在另一个URI下找到对请求的响应" - Rickroll不是对原始请求的响应.它与我的网站无关!"当收到POST(或PUT/DELETE)响应时,客户端应该假设服务器已经收到了数据,并且应该向给定的URI发出新的GET请求." 303描述的最后一句不适用于我的重定向.

307临时重定向(自HTTP/1.1起)
在这种情况下,请求应该使用另一个URI重复; 但是,未来的请求仍应使用原始URI.与历史上实现302的方式相反,在重新发出原始请求时不允许更改请求方法.例如,应该使用另一个POST请求重复POST请求.[30]

"在这种情况下,请求应该使用另一个URI重复;但是,将来的请求仍应使用原始URI." 是! 这就是我的重定向."...重新发出原始请求时,不允许更改请求方法.例如,应使用另一个POST请求重复POST请求." 不幸的是,这不适用于我的重定向.我的网站甚至在他们提交表单(POST方法)时随机Rickrolls用户.

308永久重定向(RFC 7538)
应使用另一个URI重复请求和所有将来的请求.307和308并行302和301的行为,但不允许HTTP方法改变.因此,例如,将表单提交给永久重定向的资源可能会顺利进行.[31]

308具有与301相同的问题,因为并非所有将来的请求都应该转到Rickroll视频.此外,不允许改变该方法.

我的服务器应该为与我的实际站点无关的随机机会重定向发送什么HTTP响应状态代码?

Rei*_*Rei 11

HTTP响应状态代码的官方来源是RFC7231,而不是维基百科.您应该仔细阅读RFC7231第6.4节以解释3XX状态代码.

"通过随机机会重定向访问者"事物与实际重定向无关,因此符合您要求的状态代码为303,这在6.4.4节中解释如下(强调我的):

303(请参阅其他)状态代码表示服务器正在将用户代理重定向到其他资源,如Location头字段中的URI所示,该URI旨在提供对原始请求的间接响应.用户代理可以执行针对该URI 的检索请求(如果使用HTTP则为GET或HEAD请求),其也可以被重定向,并将最终结果作为原始请求的答案呈现.请注意,Location头字段中的新URI 不被视为等效于有效请求URI.

303符合您的要求有三个原因:

  1. "到不同的资源":访问者重定向到的资源与他们最初请求的资源不同.
  2. "执行检索请求":使用GET或HEAD请求获取最终资源.
  3. "不等同于":原始请求URI不能被新URI替换,因为它不等同,换句话说,它是临时的.

为什么不302?由于第6.4.3节(强调我的)中的这部分解释:

由于历史原因,用户代理可以将请求方法从POST 更改为GET以用于后续请求.

换句话说,用户代理可以使用相同的请求方法或不同的请求方法.规范允许的灵活性302不符合您的要求.

  • 之前从未听说过303,感谢您引起我的注意.我将从现在开始使用它. (4认同)