cli*_*ait -2 redirect http http-status-codes http-redirect server
我的网站有1%的随机机会将访问者重定向到此YouTube视频.
服务器当前发送旧的302,但我希望它具有更好的语义.
我不知道重定向是永久的还是临时的.从某种意义上说,它是永久性的,人们总是有1%的机会被重定向,而且这是暂时的,因为人们不会每次都被重定向.
当前的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符合您的要求有三个原因:
为什么不302?由于第6.4.3节(强调我的)中的这部分解释:
由于历史原因,用户代理可以将请求方法从POST 更改为GET以用于后续请求.
换句话说,用户代理可以使用相同的请求方法或不同的请求方法.规范允许的灵活性302不符合您的要求.
归档时间: |
|
查看次数: |
293 次 |
最近记录: |