asp.net-mvc 对 HTTP POST 请求的正确响应是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/420103/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the correct response to an HTTP POST request?
提问by Giraffe
For a POST method, the W3 specs say:
对于 POST 方法，W3 规范说：
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see Section 10.4).
如果在源服务器上创建了资源，则响应应该是 201（已创建）并包含一个描述请求状态和引用新资源的实体，以及一个 Location 头（参见第 10.4 节）。
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-05.txt(section 8.5)
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-05.txt（第 8.5 节）
The standard response actually seems to be to send a Redirect to the newly created resource.
标准响应实际上似乎是向新创建的资源发送重定向。
I'm building my site with ASP.NET MVC, and tried to follow the spec, so created a ResourceCreatedResultclass:
我正在使用 ASP.NET MVC 构建我的网站，并尝试遵循规范，因此创建了一个ResourceCreatedResult类：
public class ResourceCreatedResult : ActionResult
{
public string Location { get; set; }
public override void ExecuteResult(ControllerContext context)
{
context.HttpContext.Response.Clear();
context.HttpContext.Response.StatusCode = 201;
context.HttpContext.Response.ClearHeaders();
context.HttpContext.Response.AddHeader("Location", Location);
}
}
And my action looks something like this:
我的动作看起来像这样：
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult CreateNew(string entityStuff)
{
Entity newEntity = new Entity(entityStuff);
IEntityRepository entityRepository = ObjectFactory.GetInstance<IEntityRepository>();
entityRepository.Add(newEntity);
ActionResult result = new ResourceCreatedResult()
{ Location = Url.Action("Show", new { id = newEntity.Id }) };
return result;
}
However, IE, Firefox and Chrome all fail to redirect to the new resource. Have I messed up generating the correct response, or do web browsers not expect this type of response, instead relying on servers to send a Redirect response?
但是，IE、Firefox 和 Chrome 都无法重定向到新资源。我是否搞砸了生成正确的响应，或者 Web 浏览器不期望这种类型的响应，而是依赖服务器发送重定向响应？
采纳答案by S.Lott
Redirect after post or post/redirect/get is something your application must do to be user friendly.
发布后重定向或发布/重定向/获取是您的应用程序必须执行的操作才能使用户友好。
Edit. This is above and beyond the HTTP specifications. If we simply return a 201 after a POST, the browser back button behaves badly.
编辑。这超出了 HTTP 规范。如果我们在 POST 后简单地返回 201，则浏览器的后退按钮表现不佳。
Note that Web Services requests (which do NOT respond to a browser) follow the standard completely and do NOT redirect after post.
请注意，Web 服务请求（不响应浏览器）完全遵循标准并且不会在发布后重定向。
It works like this.
它是这样工作的。
The browser POSTS the data.
Your application validates the data. If it's invalid, you respond with the form so they can fix it and POST.
Your application responds with a redirect.
The browser gets the redirect and does a GET.
Your application sees the GET and responds.
浏览器发布数据。
您的应用程序验证数据。如果它无效，您可以使用表单进行回复，以便他们可以修复它并发布。
您的应用程序以重定向进行响应。
浏览器获取重定向并执行 GET。
您的应用程序看到 GET 并做出响应。
Now -- hey presto! -- the back button works.
现在——嘿，快！-- 后退按钮有效。
回答by dthrasher
To be explicit, browsers (including modern browsers like Firefox 3 and IE8) do not "take the hint" and follow up an HTTP 201: Createdresponse with a GET request to the URI supplied in the Location header.
明确地说，浏览器（包括像 Firefox 3 和 IE8 这样的现代浏览器）不会“接受提示”并HTTP 201: Created使用对 Location 标头中提供的 URI 的 GET 请求来跟进响应。
If you want browsers to go to the URI supplied in the Location header, you should send an HTTP 303: See Otherstatus instead.
如果您希望浏览器转到 Location 标头中提供的 URI，则应HTTP 303: See Other改为发送状态。
回答by Greg Inozemtsev
My solution is to respond with a '201 Created' containing a simple page with a link to the new resource, and a javascript redirect using location.replace().
我的解决方案是使用“201 Created”响应，其中包含一个带有新资源链接的简单页面，以及使用 location.replace() 的 javascript 重定向。
This lets the same code work for API and browser requests, plays nicely with Back and Refresh buttons, and degrades gracefully in old browsers.
这让相同的代码可以用于 API 和浏览器请求，可以很好地与后退和刷新按钮配合使用，并在旧浏览器中优雅地降级。
回答by Pierre-Yves Gillier
As stated in the spec the response SHOULD be a HTTP 201 with redirect. So it isn't mandatory for a browser vendor to implement the correct answer...
如规范中所述，响应应该是带有重定向的 HTTP 201。因此，浏览器供应商不一定要实施正确的答案......
You should try to change to a 30x code to see if it is correctly redirected. If so, it's a browser problem, else it may come from your code (I don't know anything in ASP.NET so I can't "validate" your code)
您应该尝试更改为 30x 代码以查看它是否正确重定向。如果是这样，则是浏览器问题，否则它可能来自您的代码（我对 ASP.NET 一无所知，因此无法“验证”您的代码）
回答by MarkKGreenway
Shouldn't that only count for when something is "Created" and therefore a simple redirect to action should be genuinely sufficient?
难道这不应该只在某些东西被“创建”时才算数，因此一个简单的动作重定向应该真的就足够了吗？
