当前位置 博文首页 > 文章内容

    整理-常见HTTP状态码

    作者: 栏目:未分类 时间:2020-09-28 17:01:18

    本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
    说我们IIS7站长博客,有一篇博文用了他们的图片。
    要求我们给他们一张图片6000元。要不然法院告我们

    为避免不必要的麻烦,IIS7站长博客,全站内容图片下架、并积极应诉
    博文内容全部不再显示,请需要相关资讯的站长朋友到必应搜索。谢谢!

    另祝:版权碰瓷诈骗团伙,早日弃暗投明。

    相关新闻:借版权之名、行诈骗之实,周某因犯诈骗罪被判处有期徒刑十一年六个月

    叹!百花齐放的时代,渐行渐远!



    常见HTTP状态码

    本内容摘抄自《RESTful WebServices》 中文译本附录B '42种常见的HTTP响应代码'。
    原文作者:Leonard Ricbardson & Sam Ruby
    翻译:徐涵、李红军、胡伟

    1. 三至七种最基本的响应代码

    • 200('OK')
      一切正常。实体主体中的文档(若存在的话)是某资源的表示。

    • 400("Bad Request")
      客户端方面的问题。实体主体中的文档(若存在的话)是一个错误消息。该错误消息通常无济于事,因为客户端无法修复服务器端方面的问题。

    • 301(“Moved Permanently”)
      当客户端触发的动作引起了资源URI的变化时发送此响应代码。另外,当客户端向一个资源的旧URI发送请求时,也发送此响应代码。

    • 404(“Not Found”)和410(“Gone”)
      当客户端所请求的URI不对应任何资源时,发送此响应代码。404用于服务端不知道客户端请求那个资源的情况;410用于服务端知道客户端所请求的资源曾经存在,但现在已经不存在了的情况。

    • 409(“Conflict”)
      当客户端试图执行一个“会导致一个或多个资源处于不一致状态”的操作时,发送此响应代码。

    SOAP Web服务只使用响应代码200(”OK“)和(“Internal Server Error”)。无论你发给SOAP服务器的数据有问题,还是服务器在处理数据的过程中出现问题,或者SOAP服务器出现内部问题,SOAP服务器均发送500(“Internal Server Error”)。客户端只有查看SOAP文档主体(body)(其中包含错误的描述)才能获知错误原因。客户端无法仅靠读取响应的前三个字节得知请求成功与否。

    2. 状态码系列

    1XX:通知

    1XX系列响应代码仅在与HTTP服务器沟通时使用。

    • 100(“Continue”)
      重要程度:中等,但(写操作时)很少用。

    这是对HTTP LBYL(look-before-you-leap)请求的一个可能的响应。该响应代码表明: 客户端应重新发送初始请求,并在请求中附上第一次请求时未提供的(可能很大或者包含敏感信息的)表示 。客户端这次发送的请求不会被拒绝。对LBYL请求的另一个可能的响应是417(“Expectation Failed”)。

    请求报头:要做一个LBYL请求,客户端必须把Expect请求报头设为字符串“100-continue”。除此以外,客户端还需要设置其他一些报头,服务器将根据这些报头决定是响应100还是417。


    • 101(“Switching Protocols”)
      重要程度:非常低。

    当客户端通过在请求里使用Upgrade报头,以 通知服务器它想改用除HTTP协议之外的其他协议时,客户端将获得此响应代码101响应代码表示“行,我现在改用另一个协议了” 。通常HTTP客户端会在收到服务器发来的101响应后关闭与服务器的TCP连接。101响应代码意味着,该客户端不再是一个HTTP客户端,而将成为另一种客户端。尽管可以通过Upgrade报头从HTTP切换到HTTPS,或者从HTTP1.1切换到某个未来的版本,
    但实际使用Upgrade报头的情况比较少。Upgrade报头也可用于HTTP切换到一个完全不同的协议(如IRC)上,但那需要在Web服务器切换为一个IRC服务器的同时,Web客户端切换为一个RIC的客户端,因为服务器将立刻在同一个TCP连接上开始使用新的协议。

    请求报头:客户端把Upgrade报头设置为一组希望使用的协议。
    响应报头:如果服务器同意切换协议,它就返回一个Upgrade报头,说明它将切换到那个协议,并附上一个空白行。服务器不用关闭TCP连接,而是直接在该TCP连接上开始使用新的协议。

    2XX:成功

    2XX系列响应代码表明操作成功了。

    • 200(“OK”)
      重要程度:非常高

    一般来说,这是客户端希望看到的响应代码。它表示服务器 成功执行了客户端所请求的动作 ,并且在2XX系列里没有其他更适合的响应代码了。

    实体主体:对于GET请求,服务器应返回客户端所请求资源的一个表示。对于其他请求,服务器应返回当前所选资源的一个表示,或者刚刚执行的动作的一个描述。

    有效负载:

    • GET:在响应中发送与所请求的资源相应的实体。
    • HEAD:响应只有HTTP头字段,并且没有响应中发送的有效负载。
    • POST:响应通常包含有关在请求中执行的进度状态表示或操作结果的信息。
    • PUT:发送请求的进度状态表示作为响应
    • DELETE:发送请求的进度状态表示作为相应
    • OPTIONS:使用Allow标头与资源关联的有效请求方法列表。例如:1。
    • TRACE:结束服务器接受的请求消息的表示。

    1:

    Allow: HEAD, GET, OPTIONS
    Content-Length: 18
    Content-Type: text/plain; charset=UTF-8
    Date: Thu, 06 Apr 2017 06:43:59 GMT
    Server: Apache-Coyote/1.1


    • 201("Created")
      重要程度:高

    当服务器 依照客户端的请求创建了一个新资源时 ,发送此响应代码。

    响应报头:Location报头应包含指向新创建资源的规范URI。
    实体主体:应该给出新创建的描述与连接。若已经在Location报头里给出了新资源的URI,那么可以用新资源的一个表示作为实体主体。


    • 202(“Accepted”)
      重要程度:中等。

    客户端的请求无法或将不被实时处理 。请求稍后会被处理。请求看上去是合法的,但在实际处理它时有出现问题的可能。
    若一个请求触发了一个异步操作,或者一个需要现实世界参与的动作,或者一个需要很长时间才能完成且没必要让Web客户端一直等待的动作时,这个响应代码是一个合适的选择。

    响应报头:应该把未处理完的请求暴露为一个资源,以便客户端稍后查询其状态。Location报头可以包含指向该资源的URI。

    实体主体:若无法让客户端稍后查询请求的状态,那么至少应该提供一个关于何时能处理请求的估计。


    • 203(”Non-Authoritative Information“)
      这个响应代码跟200一样,只不过服务器想让客户端知道,有些响应报头并非来自服务器 ——他们可能是从客户端先前发送的一个请求里复制的,或者从第三方得到的。

    响应报头:客户端应明白某些报头可能是不准确的,某些响应报头可能不是服务器自己生成的,所以服务器也不知道其含义。


    • 204("No Content")
      重要程度:高

    若服务器拒绝对PUT、POST或者DELETE请求返回状态信息或表示,那么通常采用此响应代码。服务器也可以对GET请求返回此响应代码,这表明“客户端请求的资源存在,但其表示是空的”。注意与304(“Not Modified”)的区别。204常常用在Ajax应用里。服务器通过这个响应代码高数客户端: 客户端的输入以被接受,但客户端不应该改变任何UI元素

    实体主体:不允许。


    • 205(”Reset Content“)
      重要程度:低。

    它与204类似,但与204不同的是, 它表明客户端应重置数据源的视图或数据结构 。假如你在浏览器里提交一个HTML表单,并得到响应代码204,那么表单里的各个字段值不变,可以继续修改他们;但假如得到的响应代码205,那么表单里的各个字段将被重置为它们的初始值。从数据录入方面将:204适合对单挑记录做一系列编辑,而205适于连续输入一组记录。


    • 206(”Partial Content“)
      重要程度:对于支持部分GET(partial GET)的服务而言”非常高“,其他情况下”低“。

    它跟200类似,但 它用于对部分GET请求(即使用Range请求报头的GET请求)的响应 。部分GET请求常用于大型二进制文件的断点续传。

    请求报头:客户端为Range请求报头设置一个值。
    响应报头:需要提供Date报头。ETag报头与Content-Location报头的值应该跟正常GET请求相同。

    若实体主体是单个字节范围(byte range),那么HTTP响应里必须包含一个Content-Range报头,以说明本相应返回的是表示的哪个部分,若实体主体是一个多部份实体(multipart entity)(即该实体主体由多个字节范围重构成),那么每一个部分都要有自己的Content-Range报头。

    实体主体:不是整个表示,而是一个或者多个字节范围。

    3XX 重定向

    3XX系列响应代码表明;客户端需要做些额外工作才能得到所需要的资源。它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求,才能得到所需的表示。那个URI就包含在Location响应报头里。

    • 300(”Multiple Choices“)
      重要程度:低

    若被请求的资源在服务器端存在多个表示,而服务器不知道客户端想要的是哪一个表示时,发送这个响应代码。或者当客户端没有使用 Accept-* 报头来指定一个表示,或者客户端所请求的表示不存在时,也发送这个响应代码 。在这种情况下,一种选择是,服务器返回一个首选表示,并把响应代码设置为200,不过它也可以返回一个包含该资源各个表示的URI列表,并把响应代码设为300。

    响应报头:如果服务器有首选表示,那么它可以在Location响应报头中给出这个首选表示的URI。跟其他3XX响应代码一样,客户端可以自动跟随Location中的URI。

    实体主体:一个包含该资源各个表示的URI的列表。可以在表示中提供一些信息,以便用户做出选择。


    • 301(”Moved Permanently“)
      重要程度:中等。

    服务器知道客户端视图访问的是那个资源,但它不喜欢客户端调用当前URI来请求该资源。 他希望客户端记住另一个URI,并在今后的请求中使用那个新的URI 。你可以通过这个响应代码来防止由于URI变更而导致老URI失效。

    响应报头:服务器应该把规范URI放在Location响应报头里。
    实体主体:服务器可以发送一个包含新URI的信息,不过这不是必需的。


    • 302(”Found“)
      重要程度:应该了解,特别是编写客户端时。 但我不推荐使用它

    这个响应代码是造成大多数重定向方面的混乱的最根本原因。他应该是像307那样被处理。实际上,在HTTP 1.0中,响应代码302的名称是”Moved Temporarily“,不幸的是,在实际生活中,绝大多数客户端拿它像303一样处理。它的不同之处在于当服务器为客户端的PUT,POST或者DELETE请求返回302响应代码时,客户端要怎么做。

    为了消除这一混淆,在HTTP 1.1 中,该响应代码被重命名为"Found",并新加了一个响应代码307。这个响应代码目前仍在广泛使用,但它的含义是混淆的,所以我建议你的服务发送307或者303,而不要发送302。除非你知道正在与一个不能理解303或者307的 HTTP 1.0客户端交互。

    响应报头:把客户端应重新请求的那个URI放在Location报头里。
    实体主体:一个包含指向新URI的链接的超文本文档(就想301一样)。


    • 303(”See Other“)
      重要程度:高。

    请求已经被处理,但服务器不是直接返回一个相应文档,而是返回一个响应文档的URI。该相应文档可能是一个静态的状态信息,也可能是一个更有趣的资源。对于后一种情况,303是一种另服务器可以” 发送一个资源的表示,而不强迫客户端下载其所有数据 “的方式。客户端可以向Location报头里的URI发送GET请求,但他不是必须怎么做。

    303响应代码是一种规范化资源URI的好方法。一个资源可以有多个URIs,但每个资源的规范URI只有一个,该资源的所有其他URIs都通过303指向该资源的规范URI,例如:303可以把一个对http://www.example.com/software/current.tar.gz的请求重定向到http://www.example.com/software/current.tar.gz。

    响应报头:Location报头里包含资源的URI。
    实体主体:一个包含指向新URI的链接的超文本文档。


    • 304(”Not Modeified“)
      重要程度:高。

    这个响应代码跟204(”No Content“)类似:响应实体主体都必须为空。但204用于没有主体数据的情况,而304用于 有主体数据,但客户端已拥有该数据,没必要重复发送的情况 。这个响应代码可用于条件HTTP请求(conditional HTTP request)。如果客户端在发送GET请求时附上了一个值为Sunday的if-Modified-Since报头,而客户端请求的表示在服务器端来自星期日(Sunday)以来一直没有改变过,那么服务器可以返回一个304响应。服务器也可以返回一个200响应,但由于客户端已拥有该表示,因此重复发送该表示只会白白浪费宽带。

    响应报头:需要提供Date报头。Etag与Content-Location报头的值,应该跟返回200响应时的一样。若Expires,Cache-Control及Vary报头的值自上次发送以来已经改变,那么就要提供这些报头。

    实体主体:不允许。


    • 305("Use Proxy")
      重要程度:低

    这个响应代码用于 告诉客户端它需要再发一次请求,但这次要通过一个HTTP代理发送,而不是直接发送给服务器 。这个响应代码使用的不多,因为服务器很少在意客户端是否使用某一特定代理。这个代码主要用于基于代理的镜像站点。

    现在,镜像站点(如http://www.example.com.mysite.com/)包含跟原始站点(如 http://www.example.com/)一样的内容,但具有不同的URI,原始站点可以通过307把客户端重新定向到镜像站点上。假如有基于代理的镜像站点,那么你可以通过把 http://proxy.mysite.com/设为代理,使用跟原始URI(http://www.example.com/)一样的URI来访问镜像站点。这里,原始站点example.com可以通过305把客户端路由到一个地理上接近客户端的镜像代理。web浏览器一般不能正确处理这个响应代码,这是导致305响应代码用的不多的另一个原因。

    响应报头:Location包头里包含代理的URI。


    • 306 未使用
      重要程度:无

    306响应代码没有在HTTP标准中定义过。


    • 307(”Temporary Redirect“)
      重要程度:高。

    请求还没有被处理,因为所请求的资源不在本地:它在另一个URI处。客户端应该向那个URI重新发送请求。就GET请求来说,它只是请求得到一个表示,该响应代码跟303没有区别。当服务器希望把客户端重新定向到一个镜像站点时,可以用307来响应GET请求。但对于POST,PUT及DELETE请求,他们希望服务器执行一些操作,307和303有显著区别。对POST、PUT或者DELETE请求响应303表明:操作已经成功执行,但响应实体将不随本响应一起返回,若客户端想要获取响应实体主体,它需要向另一个URI发送GET请求。而307表明: 服务期尚未执行操作,客户端需要向Location报头里的那个URI重新提交整个请求

    响应报头:把客户端应重新请求的那个URI放在Location报头里。
    实体主体:一个包含指向新URI的链接的超文本文档。

    4XX:客户端错误