使用创建的 201 进行重定向
有没有办法通过 201 答案重定向？
RFC 规定新创建的资源必须在 Location 标头中指定，我确实指定了它。我假设浏览器会重定向，但事实并非如此，即使页面没有内容。
我希望用户在 POST 操作之后重定向到新资源。因此，我很想使用 303 See Other，但 201 似乎更合适。
那么，有没有什么方法可以自动重定向流行的浏览器而无需用户干预且不依赖Javascript呢？
Is there a way to redirect through a 201 answer?
The RFC specifies that the newly created resource must be specified in the Location header, and I do specify it. I assumed that the browser would redirect but it doesn't, even if the page has no content.
I want the user, after the POST action, to get redirected to the new resource. I'm therefore tempted to use 303 See Other but a 201 seems more appropriate.
So, is there any way to automatically redirect popular browsers without user intervention and without relying on Javascript?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为您混淆了两种不同的语义响应 - 一种是告诉客户端您已成功创建资源以及它在哪里。客户是否去取是另一回事。
第二个是告诉客户端它为其请求的资源发送了错误的位置 URI，并且应该使用不同的 URI 重试。
在这种情况下，303 是合适的 - 事实上，明确建议这样做：（
来自 rfc)
它主要用于允许 POST 操作的输出将用户代理重定向到选定的资源，因为这样做会以可单独识别的形式提供与 POST 响应相对应的信息、添加书签和缓存，与原始请求无关。
I think you're confusing two different semantic responses - one is telling the client that you successfully created a resource, and where it is. Whether the client goes to fetch it or not is a different story.
The second is telling the client that it has sent the wrong location URI for a resource it's requesting - and that it should try again, but with a different URI.
A 303 is appropriate in this case - in fact, it's explicitly recommended for this:
(from rfc)
It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.
浏览器将通过 3xx 状态代码之一执行重定向操作，该规范没有定义用户代理必须使用 201 进行重定向。您可以尝试发送刷新标头以查看它是否强制重定向到
Location标头，但我不会指望它。为什么不坚持使用 3xx 响应呢？The browser will enact a redirect action through one of the 3xx status codes, the specification doesn't define that a user agent must redirect with a 201. You could try sending a refresh header to see if it forces a redirect to the
Locationheader, but I wouldn't count on it. Why not stick with a 3xx response?您可以发送
Refresh标头。You could send a
Refreshheader.我是第一次处理这个问题，这就是我决定要做的：
GET /user/new->200 Ok附有用户注册表。POST /用户->201 创建一个新用户，使用与GET /user路由相同的内容进行响应。GET /用户->对于经过身份验证的用户，200 Ok使用用户个人资料页面，或者对于匿名访问者，307 临时重定向到/login，该页面链接到 <代码> /用户/新。更新
我发现这是一个坏主意，因为如果用户刷新作为
POST /user响应而呈现的页面，他们会重新发送帖子数据。我会将答案留在这里，以防其他人有同样的好主意。I am dealing with this for the first time, and this is what I have decided to do:
GET /user/new->200 Okwith user registration form.POST /user->201 Createda new user, respond with the same content as theGET /userroute.GET /user->200 Okwith the user profile page for the authenticated user, or, for anonymous visitors,307 Temporary Redirectto/login, which links to/user/new.update
I have found out that this is a bad idea, because if the user refreshes the page that was rendered as a response for
POST /user, they resend the post data. I will leave the answer here in case anyone else has the same brilliant idea.