http Response状态码

Posted 2023-04-06

参考技术A -1xx ： 报告的 -请求被接收到，继续处理

-2xx ： 成功 - 被成功地接收（received），理解（understood），接受（accepted）的动作 。

-3xx ： 重发 - 为了完成请求必须采取进一步的动作。

-4xx ： 客户端出错 - 请求包括错的语法或不能被满足。

-5xx ： 服务器出错 - 服务器无法完成显然有效的请求

1xx系列 ：

"100" : 继续

"101" ： 转换协议

2xx系列：

"200" : OK

此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：

GET 请求资源的相应的实体已经包含在响应里并返回给客户端。

HEAD 相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。

POST 响应里已经包含一个实体，此实体描述或者包含此POST动作执行的结果。

"201" : （Created）已创建

请求已经被服务器处理了，并且已经产生了一个新的资源。新创建的资源的URI在响应的实体里返回，但是此资源最精确的URI是在Location头域里给出的。响应应该含有一实体，此实体包含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被Content-Type头域里媒体类型指定。源服务器必须能在返回201状态码之前建立资源。一个201响应可以包含一个ETag响应头域，此头域的值指明了当前请求变量（特定表现形式的资源），也即刚刚创建的资源的实体标签（entity tag）值。

"202" :  （Accepted）接受

请求已经被接受去处理，但是还没有处理完成。请求可能会或者不会处理完成，因为存在当处理的过程中拒绝处理的情况。

"203" : 非权威信息

"204" : （No Content）无内容

服务器已经满足了请求但并没有返回一个实体而是返回更新的元信息。204状态响应主要的目的是允许输入，而不必引起用户代理当前文档视图的改变，尽管一些新的或更新了的元信息可能会应用于用户代理视图里的当前文档。

"205" : 重置内容

"206" :（Partial Content） 部分内容

服务器已经完成了客户端对资源的部分GET请求。请求必须包含一个Range头域用来指出想要的范围，并且也有可能包含一个If-Range头域来使请求成为一个条件请求。

3xx系列：

"300" : （Multiple Choices）多个选择

请求资源对应于该资源众多表现形式中的一个，每个表现形式都有一个特定的位置(location)，并且代理驱动协商（agent-driven negotiation）信息被提供以便用户（或用户代理）能选择一个更合适的表现形式并重定向它的请求到那个表现形式的位置。

"301" : （Moved Permanently）永久移动，永久的重定向

请求资源被赋于一个新的永久的URI，并且任何将来对此资源的引用都会利用此301状态响应。新的永久URI应该在响应中被Location头域给定。除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。如果客户端接收了一个来自非GET或HEAD请求方法的301响应，那么用户代理不能自动重定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。

"302" : (Found)发现

请求的资源暂时地存放在一个不同的URI下。因为重定向的地址可能有时会被改变，客户端应该继续为将来的请求利用请求URI(Request-URI)。302响应是只有在Cache-Control或Expires头域指明的情况下才能被缓存。临时的URI应该在Location头域里指定。除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。如果客户端接收了一个来自非GET或HEAD请求方法的302响应，那么用户代理不能自动重定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。

"303": (See Other)见其它,临时重定向

请求的响应被放在一个不同的URI下， 并且应该用GET方法获得那个资源 。它的主要目的是响应一个POST请求通过指引client访问一个资源。不同的URI应该在Location头域里指定。除非请求方法是HEAD，否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接。

"304" : （Not Modified）没有被改变

如果客户端已经执行了条件GET请求，并且访问服务器的资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该以此状态码响应。304响应不能包含一个消息主体(messagebody)，并且在头域后面总是以一个空行结束。

"305" : （Use Proxy）使用代理

请求资源必须能通过代理访问，代理的地址在响应的Location头域里指定。Location头域指定了代理的URI。接收者被期望通过代理重试此请求，305响应必须被源服务器产生。

"307": （Temporary Redirect）临时重发

请求的资源临时存在于一个不同的URI下。由于新的URI可能有时会改变，所以客户端应该继续利用此请求URI（Request-URI）为将来的请求。307响应只有被Cache-Control或Expire头域指明时才能被缓存。临时URI应该在响应的Location头域里给定。否则此响应应该包含一个超文本提示和一个指向新URI的超文本链接，因为许多HTTP/1.1以前的用户代理不能理解307状态响应。因此，此提示应该包含用户在新的URI上重试原始请求的必需信息。如果307状态响应.对应的请求的方法不是GET或HEAD，那么用户代理不能自动重定向此请求除非它能被用户确认，因为因为这可能会改变请求提交的条件。

4xx系列：

  "400"： 坏的请求

请求不能被服务器理解，由于错误的语法。客户端不应该在没有改变请求的情况下重试请求

 "401":  未授权的

服务器需要对请求进行用户认证

"403":(Forbidden）禁用

服务器理解此请求，但拒绝满足此请求。认证是没有作用的，并且请求不应该被重试。如果请求方法是HEAD并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么404 状态码(NotFound)响应将被使用。

 " 404"： 请求的资源不存在

服务器并没有找到任何可以匹配请求URI 的资源,此状态码通常被使用，当服务器不希望精确指出请求为何被拒绝，或者当没有任何其它响应可用时。

 "405"： 请求的资源是存在的，但该资源不支持该请求方法

 "406" : 不接受的

 "407" : 需要代理验证

 "408" ： 请求超时

 "409" ： 冲突

 "410" ： 不存在

 "411" ： 长度必需

 "412" ：先决条件失败

 "413" ： 请求实体太大

 "414" ： 请求URI太大

 "415" ： 不被支持的媒体类型

 "416" ： 请求的范围不满足

 "417" ： 期望失败

5xx系列：

"500" :（Internal Server Error） 服务器内部错误

服务器遇到了一个意外条件，此条件阻止服务器满足此请求。

501：（Not Implemented）服务器不能识别该请求方法或服务器暂未实现方法

服务器没有能力去满足请求。当服务器不能识别请求方法并且不支持它请求资源的时候，这个响应是很合适的。

"502" : （Bad Gateway）坏网关

此响应说明：作为网关或代理的服务器从上游（upstream）服务器接收了一个无效的响应。

"503" :（Service Unavailable） 服务不能获得

由于服务器暂时地过载或维护，服务器不能处理请求

"504": （Gateway Timeout）网关超时

作为网关或代理的服务器在不能及时地接收一个从URI指定的上游（upstream）服务器（例如：HTTP，FTP，LDAP服务器）或者其他的辅助性服务器（例如：DNS服务器）的响应

"505" : HTTP版本不支持

301永久重定向，302,303,307都表示非永久的重定向，他们之间的区别主要和http client版本相关。http/1.0版本的http client 发送一个POST请求，当收到http/1.0版本的服务器的302响应码时，将以GET请求Location中的url而不是继续使用POST。http/1.1通过303实现了http/1.0中的同样的功能。303对于http/1.0来说是不可见的。http/1.1中的307则是用来替代302的，当http client为http/1.0时就响应302,当为http/1.1时就响应307.302,303,307功能是一样的，主要是为了解决兼容性才这样设计的吧。

Response.Redirect HTTP 状态码

【中文标题】Response.Redirect HTTP 状态码

【英文标题】：Response.Redirect HTTP status code

【发布时间】：2010-12-15 23:03:12

【问题描述】：

为什么 ASP/ASP.NET Response.Redirect 使用 HTTP-302 状态代码（“临时移动”），即使在大多数情况下 HTTP-301 状态代码（“永久移动”）更合适？

【参考方案1】：

状态为 301 的响应应该是可缓存的，我认为您不希望大多数 ASP/ASP.NET 重定向具有这种行为。

如果需要，ASP.NET 4.0 有 RedirectPermanent 方法。

【讨论】：

ASP.NET 4.0 附带的新的 RedirectPermanent 方法非常方便！不幸的是，我正在进行的项目正在运行 2.0...

【参考方案2】：

我已经成功地使用了这个方便的永久重定向：

public void RedirectPermanent(string newPath)

  HttpContext.Current.Response.Clear();
  HttpContext.Current.Response.Status = "301 Moved Permanently";
  HttpContext.Current.Response.AddHeader("Location", newPath);
  HttpContext.Current.Response.End();

【讨论】：

我也在使用这个，但我只是想知道为什么我必须这样做“解决方法”。

【参考方案3】：

Response.Redirect 的一个常见用例是在回发后将用户移动到服务器端代码中的另一个页面，例如类似于

private void MyButton_Click(object sender, EventArgs e)

    if (some condition) 
         Response.Redirect("ShowProduct.aspx");
     else 
         Response.Redirect("SorryOutOfStock.aspx");
    

在这些情况下，301 将是完全错误的。事实上，我认为上述情况（在一些 UI 交互后有条件地将用户移动到另一个页面）是 Response.Redirect 比 real this-page-moved-to- 更常见的用法another-URL-forever 场景（返回代码 301 是合适的）。

【参考方案4】：

除了 Heinzi 的回答之外，网络上唯一可能会引起 301 关注的实体是搜索引擎。大多数浏览器不会跟踪和记录 301，以便自动重定向初始 URL 的任何后续请求。浏览器对待 301 的方式与对待 302 的方式相同。因此，在 ASP.NET 中生成的动态内容中的 302 非常合适。

【讨论】：

是的，我担心的是搜索蜘蛛。

【参考方案5】：

你得到的错误不是由于 response.redirect ！

HTTP 响应状态代码 301 Moved Permanently 用于永久重定向，这意味着使用收到 301 Moved Permanently 响应的 URL 的当前链接或记录应更新为响应的 Location 字段中提供的新 URL。

【讨论】：

如果您没有在每个答案中不断发布指向onfrnz.com/search 的链接会很好，这有点垃圾邮件。谢谢。