精华内容
下载资源
问答
  • Http状态码406(Not Acceptable) 错误问题解决方法

    万次阅读 多人点赞 2018-11-08 20:13:31
    状态码406:HTTP协议状态码种,表示无法使用请求的内容特性来响应请求的网页。说白了就是后台的返回结果前台无法解析就报406错误。 示例代码中请求代码,后台代码均正常,且有返回信息。如下图: $.ajax({ ...

    状态码406:HTTP协议状态码的一种(4xx表示客户端的问题),表示客户端无法解析服务端返回的内容。说白了就是后台的返回结果前台无法解析就报406错误。

    示例代码中请求代码,后台代码均正常,且有返回信息。如下图:

    $.ajax({
                url:'http://localhost:8080/findDsrwByDsrwid',
                type : 'post',
                data :{
                    id : cztj
                },
                dataType:'json',
            }).success(function(result){
              }

    那我们来看看网页状态:

    状态码:406,请求头(Request Headers)中看到Accept优先是application/json格式,而响应头(Response Hraders)中却发现返回信息的格式是“text/html”,前台无法解析,需将结果转换成json格式返回给前台。

    解决方案:

    jackson开源工具(springMVC天然支持)

    导入jackson-core和jackson-mapper-asl的依赖包,如果你是maven工程,在pom加入

     <!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core -->
        <dependency>
          <groupId>com.fasterxml.jackson.core</groupId>
          <artifactId>jackson-core</artifactId>
          <version>2.1.4</version>
        </dependency>
    
          <!-- https://mvnrepository.com/artifact/org.codehaus.jackson/jackson-mapper-asl -->
          <dependency>
              <groupId>org.codehaus.jackson</groupId>
              <artifactId>jackson-mapper-asl</artifactId>
              <version>1.9.12</version>
          </dependency>

    此时还需要关注springMVC的一个配置,具体原因请看原理解析。

    原理解析:

    为什么只要导入jar就好了呢?是因为spring mvc 配置了 <mvc:annotation-driver/> 后 ,如果classpath 里面包含jackson 包,则自动注册MappingJackson2HttpMessageConverter,从而支持json 输出。

    这是springMVC中的一句配置

    <!-- 能支持springmvc更高级的一些功能,JSR303,快捷的ajax -->
    <mvc:annotation-driven/>

    且annotation-driver是被AnnotationDrivenBeanDefinitionParser解析,这里提供另外一篇博文,希望有所帮助。

    spring mvc jackson 支持原理分析_taotoxht的专栏-CSDN博客_jackson 原理

    结果展示:

    ————————————————————————————————————————————————————

    2020.01.30:,今天搭了另外一个项目的环境,项目依赖中已有jackson-annotations-*.jar,jackson-core-.jar,jackson-databind-.jar 包,打开注解驱动依然报406,如果有同学试了以上方案不行的话,可以试着尝试fastjson替代jackson,具体是:

    引入jar包:

            <!-- https://mvnrepository.com/artifact/com.alibaba/fastjson -->
            <dependency>
                <groupId>com.alibaba</groupId>
                <artifactId>fastjson</artifactId>
                <version>1.2.58</version>
            </dependency>

    注解驱动配置为:

    	<mvc:annotation-driven>
    		<mvc:message-converters register-defaults="true">
    			<!-- 配置Fastjson支持 -->
    			<bean class="com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter">
    				<property name="supportedMediaTypes">
    					<list>
    						<value>application/json</value>
    						<value>text/html;charset=UTF-8</value>
    					</list>
    				</property>
    <!--				<property name="features">
    					<list>
    						<value>WriteMapNullValue</value>
    						<value>QuoteFieldNames</value>
    					</list>
    				</property>-->
    			</bean>
    		</mvc:message-converters>
    	</mvc:annotation-driven>

    结果: 

    展开全文
  • 状态码详解

    万次阅读 2021-09-29 14:26:47
    状态码 含义 100 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求...
    状态码 	含义
    100 	客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
    101 	服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade 消息头中定义的那些协议。   只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP 版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源。
    102 	由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执行。
    200 	请求已成功,请求所希望的响应头或数据体将随此响应返回。
    201 	请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话,应当返回 '202 Accepted'。
    202 	服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。   返回202状态码的响应的目的是允许服务器接受其他过程的请求(例如某个每天只执行一次的基于批处理的操作),而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息,以及指向处理状态监视器或状态预测的指针,以便用户能够估计操作是否已经完成。
    203 	服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如,包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
    204 	服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响应可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。   如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。   由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。
    205 	服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。   与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。
    206 	服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。   该请求必须包含 Range 头信息来指示客户端希望得到的内容范围,并且可能包含 If-Range 来作为请求条件。   响应必须包含如下的头部域:   Content-Range 用以指示本次响应中返回的内容的范围;如果是 Content-Type 为 multipart/byteranges 的多段下载,则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length,那么它的数值必须匹配它返回的内容范围的真实字节数。   Date   ETag 和/或 Content-Location,假如同样的请求本应该返回200响应。   Expires, Cache-Control,和/或 Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。   假如本响应请求使用了 If-Range 强缓存验证,那么本次响应不应该包含其他实体头;假如本响应的请求使用了 If-Range 弱缓存验证,那么本次响应禁止包含其他实体头;这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则,本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。   假如 ETag 或 Last-Modified 头部不能精确匹配的话,则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。   任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。
    207 	由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。
    300 	被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。   除非这是一个 HEAD 请求,否则该响应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择。当然,RFC 2616规范并没有规定这样的自动选择该如何进行。   如果服务器本身已经有了首选的回馈选择,那么在 Location 中应当指明这个回馈的 URI;浏览器可能会将这个 Location 值作为自动重定向的地址。此外,除非额外指定,否则这个响应也是可缓存的。
    301 	被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。   新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   如果这不是一个 GET 或者 HEAD 请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。   注意:对于某些使用 HTTP/1.0 协议的浏览器,当它们发送的 POST 请求得到了一个301响应的话,接下来的重定向请求将会变成 GET 方式。
    302 	请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。   新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   如果这不是一个 GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。   注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用 GET 方式访问在 Location 中规定的 URI,而无视原先请求的方法。状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。
    303 	对应当前请求的响应可以在另一个 URI 上被找到,而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。   新的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   注意:许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
    304 	如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。   该响应必须包含以下的头信息:   Date,除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则,那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去(正如RFC 2068中规定的一样),缓存机制将会正常工作。   ETag 和/或 Content-Location,假如同样的请求本应返回200响应。   Expires, Cache-Control,和/或Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。   假如本响应请求使用了强缓存验证,那么本次响应不应该包含其他实体头;否则(例如,某个带条件的 GET 请求使用了弱缓存验证),本次响应禁止包含其他实体头;这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。   假如某个304响应指明了当前某个实体没有缓存,那么缓存系统必须忽视这个响应,并且重复发送不包含限制条件的请求。   假如接收到一个要求更新某个缓存条目的304响应,那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。
    305 	被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。   注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。
    306 	在最新版的规范中,306状态码已经不再被使用。
    307 	请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。   新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求,否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应,因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。   如果这不是一个GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
    400 	1、语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。   2、请求参数有误。
    401 	当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。
    402 	该状态码是为了将来可能的需求而预留的。
    403 	服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息。
    404 	请求失败,请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
    405 	请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。   鉴于 PUT,DELETE 方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。
    406 	请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。   除非这是一个 HEAD 请求,否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是,规范中并没有定义任何作出此类自动选择的标准。
    407 	 与401响应类似,只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。
    408 	请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
    409 	由于和被请求的资源的当前状态之间存在冲突,请求无法完成。这个代码只允许用在这样的情况下才能被使用:用户被认为能够解决冲突,并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。   冲突通常发生于对 PUT 请求的处理中。例如,在采用版本检查的环境下,某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个(第三方)请求向冲突,那么此时服务器就应该返回一个409错误,告知用户请求无法完成。此时,响应实体中很可能会包含两个冲突版本之间的差异比较,以便用户重新提交归并以后的新版本。
    410 	被请求的资源在服务器上已经不再可用,而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能,拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的,那么就应该使用404状态码。除非额外说明,否则这个响应是可缓存的。   410响应的目的主要是帮助网站管理员维护网站,通知用户该资源已经不再可用,并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样,410响应也被用于通知客户端在当前服务器站点上,原本属于某个个人的资源已经不再可用。当然,是否需要把所有永久不可用的资源标记为'410 Gone',以及是否需要保持此标记多长时间,完全取决于服务器拥有者。
    411 	服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后,客户端可以再次提交该请求。
    412 	服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。
    413 	服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。   如果这个状况是临时的,服务器应当返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。
    414 	请求的URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。这比较少见,通常的情况包括:   本应使用POST方法的表单提交变成了GET方法,导致查询字符串(Query String)过长。   重定向URI “黑洞”,例如每次重定向把旧的 URI 作为新的 URI 的一部分,导致在若干次重定向后 URI 超长。   客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI,当 GET 后的参数超过某个数值后,可能会产生缓冲区溢出,导致任意代码被执行[1]。没有此类漏洞的服务器,应当返回414状态码。
    415 	对于当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式,因此请求被拒绝。
    416 	如果请求中包含了 Range 请求头,并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合,同时请求中又没有定义 If-Range 请求头,那么服务器就应当返回416状态码。   假如 Range 使用的是字节范围,那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时,包含一个 Content-Range 实体头,用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。
    417 	在请求头 Expect 中指定的预期内容无法被服务器满足,或者这个服务器是一个代理服务器,它有明显的证据证明在当前路由的下一个节点上,Expect 的内容无法被满足。
    421 	从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。
    422 	从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。
    422 	请求格式正确,但是由于含有语义错误,无法响应。(RFC 4918 WebDAV)423 Locked   当前资源被锁定。(RFC 4918 WebDAV)
    424 	由于之前的某个请求发生的错误,导致当前请求失败,例如 PROPPATCH。(RFC 4918 WebDAV)
    425 	在WebDav Advanced Collections 草案中定义,但是未出现在《WebDAV 顺序集协议》(RFC 3658)中。
    426 	客户端应当切换到TLS/1.0。(RFC 2817)
    449 	由微软扩展,代表请求应当在执行完适当的操作后进行重试。
    500 	服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器的程序码出错时出现。
    501 	服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。
    502 	作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
    503 	由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理500响应的方式处理它。   注意:503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
    504 	作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。   注意:某些代理服务器在DNS查询超时时会返回400或者500错误
    505 	服务器不支持,或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
    506 	由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误:被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。
    507 	服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
    509 	服务器达到带宽限制。这不是一个官方的状态码,但是仍被广泛使用。
    510 	获取资源所需要的策略并没有没满足。(RFC 2774)
    
    展开全文
  • HTTP状态码

    万次阅读 2019-07-12 11:22:32
    根据HTTP返回状态码,来判断api状态 以下是中英文HTTP返回状态码的对照信息。 1、信息 - 100 Continue - 101 Switching Protocols - 102 Processing 2、成功 - 200 OK - 201 Created - 202 Accepted - 203 .....
      2018年7月10日10:04:54
    
    根据HTTP返回状态码,来判断api状态
    
    以下是中英文HTTP返回状态码的对照信息。
    

    1、信息

    -   100 Continue
    -   101 Switching Protocols
    -   102 Processing
    

    2、成功

    -   200 OK
    -   201 Created
    -   202 Accepted
    -   203 Non-Authoritative Information
    -   204 No Content
    -   205 Reset Content
    -   207 Multi-Status
    

    3、重定向

    -   300 Multiple Choices
    -   301 Moved Permanently
    -   302 Move temporarily
    -   303 See Other
    -   304 Not Modified
    -   305 Use Proxy
    -   306 Switch Proxy
    -   307 Temporary Redirect
    

    4、请求错误

    -   400 Bad Request
    -   401 Unauthorized
    -   402 Payment Required
    -   403 Forbidden
    -   404 Not Found
    -   405 Method Not Allowed
    -   406 Not Acceptable
    -   407 Proxy Authentication Required
    -   408 Request Timeout
    -   409 Conflict
    -   410 Gone
    -   411 Length Required
    -   412 Precondition Failed
    -   413 Request Entity Too Large
    -   414 Request-URI Too Long
    -   415 Unsupported Media Type
    -   416 Requested Range Not Satisfiable
    -   417 Expectation Failed
    -   421 too many connections
    -   422 Unprocessable Entity
    -   423 Locked
    -   424 Failed Dependency
    -   425 Unordered Collection
    -   426 Upgrade Required
    -   449 Retry With
    -   451 Unavailable For Legal Reasons
    

    5、服务器错误

    -   500 Internal Server Error
    -   501 Not Implemented
    -   502 Bad Gateway
    -   503 Service Unavailable
    -   504 Gateway Timeout
    -   505 HTTP Version Not Supported
    -   506 Variant Also Negotiates
    -   507 Insufficient Storage
    -   509 Bandwidth Limit Exceeded
    -   510 Not Extended
    -   600 Unparseable Response Headers
    

    HTTP状态码

    1、信息

    这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送 1xx 响应。
    
    -   100 Continue
    客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
    
    -   101 Switching Protocols
    服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade 消息头中定义的那些协议。
    只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP 版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源。
    
    -   102 Processing
    由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执行。
    

    2、成功

    这一类型的状态码,代表请求已成功被服务器接收、理解、并接受 [1]  。
    
    -   200 OK
    请求已成功,请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。
    
    -   201 Created
    请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话,应当返回 '202 Accepted'。
    
    -   202 Accepted
    服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。
    返回202状态码的响应的目的是允许服务器接受其他过程的请求(例如某个每天只执行一次的基于批处理的操作),而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息,以及指向处理状态监视器或状态预测的指针,以便用户能够估计操作是否已经完成。
    -   203 Non-Authoritative Information
    服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如,包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
    
    -   204 No Content
    服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响应可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。
    如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。
    由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。
    
    -   205 Reset Content
    服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。
    与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。
    206 Partial Content
    服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
    该请求必须包含 Range 头信息来指示客户端希望得到的内容范围,并且可能包含 If-Range 来作为请求条件。
    
    -   207 Multi-Status
    由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。
    

    3、重定向

    这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。
    当且仅当后续的请求所使用的方法是 GET 或者 HEAD 时,用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向(例如:A->A,或者A->B->C->A),因为这会导致服务器和客户端大量不必要的资源消耗。按照 HTTP/1.0 版规范的建议,浏览器不应自动访问超过5次的重定向。
    
    -   300 Multiple Choices
    被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
    除非这是一个 HEAD 请求,否则该响应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择。当然,RFC 2616规范并没有规定这样的自动选择该如何进行。
    如果服务器本身已经有了首选的回馈选择,那么在 Location 中应当指明这个回馈的 URI;浏览器可能会将这个 Location 值作为自动重定向的地址。此外,除非额外指定,否则这个响应也是可缓存的。
    
    -   301 Moved Permanently
    被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。
    新的永久性的URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
    如果这不是一个 GET 或者 HEAD 请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
    注意:对于某些使用 HTTP/1.0 协议的浏览器,当它们发送的 POST 请求得到了一个301响应的话,接下来的重定向请求将会变成 GET 方式。
    
    -   302 Move temporarily
    请求的资源临时从不同的 URI响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。
    上文有提及。
    如果这不是一个 GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
    注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用 GET 方式访问在 Location 中规定的 URI,而无视原先请求的方法。状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。
    
    -   303 See Other
    对应当前请求的响应可以在另一个 URI 上被找到,而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。
    注意:许多 HTTP/1.1 版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
    
    -   304 Not Modified
    如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。
    该响应必须包含以下的头信息:
    Date,除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则,那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去(正如RFC 2068中规定的一样),缓存机制将会正常工作。
    ETag 和/或 Content-Location,假如同样的请求本应返回200响应。
    Expires, Cache-Control,和/或Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。
    假如本响应请求使用了强缓存验证,那么本次响应不应该包含其他实体头;否则(例如,某个带条件的 GET 请求使用了弱缓存验证),本次响应禁止包含其他实体头;这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。
    假如某个304响应指明了当前某个实体没有缓存,那么缓存系统必须忽视这个响应,并且重复发送不包含限制条件的请求。
    假如接收到一个要求更新某个缓存条目的304响应,那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。
    
    -   305 Use Proxy
    被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。
    注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。
    
    -   306 Switch Proxy
    在最新版的规范中,306状态码已经不再被使用。
    
    -   307 Temporary Redirect
    请求的资源临时从不同的URI 响应请求。
    新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求,否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应,因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。
    如果这不是一个GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
    

    4、请求错误

    这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。除非响应的是一个 HEAD 请求,否则服务器就应该返回一个解释当前错误状况的实体,以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。
    如果错误发生时客户端正在传送数据,那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前,客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据,服务器的TCP栈将向客户端发送一个重置数据包,以清除该客户端所有还未识别的输入缓冲,以免这些数据被服务器上的应用程序读取并干扰后者。
    
    -   400 Bad Request
    1、语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。
    2、请求参数有误。
    
    -   401 Unauthorized
    当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。
    
    -   402 Payment Required
    该状态码是为了将来可能的需求而预留的。
    
    -   403 Forbidden
    服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息。
    
    -   404 Not Found
    请求失败,请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。
    
    -   405 Method Not Allowed
    请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。
    鉴于 PUT,DELETE 方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。
    
    -   406 Not Acceptable
    请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。
    除非这是一个 HEAD 请求,否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是,规范中并没有定义任何作出此类自动选择的标准。
    
    -   407 Proxy Authentication Required
    与401响应类似,只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。
    
    -   408 Request Timeout
    请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
    
    -   409 Conflict
    由于和被请求的资源的当前状态之间存在冲突,请求无法完成。这个代码只允许用在这样的情况下才能被使用:用户被认为能够解决冲突,并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。
    冲突通常发生于对 PUT 请求的处理中。例如,在采用版本检查的环境下,某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个(第三方)请求向冲突,那么此时服务器就应该返回一个409错误,告知用户请求无法完成。此时,响应实体中很可能会包含两个冲突版本之间的差异比较,以便用户重新提交归并以后的新版本。
    
    -   410 Gone
    被请求的资源在服务器上已经不再可用,而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能,拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的,那么就应该使用404状态码。除非额外说明,否则这个响应是可缓存的。
    410响应的目的主要是帮助网站管理员维护网站,通知用户该资源已经不再可用,并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样,410响应也被用于通知客户端在当前服务器站点上,原本属于某个个人的资源已经不再可用。当然,是否需要把所有永久不可用的资源标记为'410 Gone',以及是否需要保持此标记多长时间,完全取决于服务器拥有者。
    
    -   411 Length Required
    服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后,客户端可以再次提交该请求。
    
    -   412 Precondition Failed
    服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。
    
    -   413 Request Entity Too Large
    服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。
    如果这个状况是临时的,服务器应当返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。
    
    -   414 Request-URI Too Long
    请求的URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。这比较少见,通常的情况包括:
    本应使用POST方法的表单提交变成了GET方法,导致查询字符串(Query String)过长。
    重定向URI “黑洞”,例如每次重定向把旧的 URI 作为新的 URI 的一部分,导致在若干次重定向后 URI 超长。
    客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI,当 GET 后的参数超过某个数值后,可能会产生缓冲区溢出,导致任意代码被执行[1]。没有此类漏洞的服务器,应当返回414状态码。
    
    -   415 Unsupported Media Type
    对于当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式,因此请求被拒绝。
    
    -   416 Requested Range Not Satisfiable
    如果请求中包含了 Range 请求头,并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合,同时请求中又没有定义 If-Range 请求头,那么服务器就应当返回416状态码。
    假如 Range 使用的是字节范围,那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时,包含一个 Content-Range 实体头,用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。
    
    -   417 Expectation Failed
    在请求头 Expect 中指定的预期内容无法被服务器满足,或者这个服务器是一个代理服务器,它有明显的证据证明在当前路由的下一个节点上,Expect 的内容无法被满足。
    
    -   421 too many connections
    There are too many connections from your internet address
    从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。
    
    -   422 Unprocessable Entity
    请求格式正确,但是由于含有语义错误,无法响应。(RFC 4918 WebDAV)
    
    -   423 Locked
    当前资源被锁定。(RFC 4918 WebDAV)
    
    -   424 Failed Dependency
    由于之前的某个请求发生的错误,导致当前请求失败,例如 PROPPATCH。(RFC 4918 WebDAV)
    
    -   425 Unordered Collection
    在WebDav Advanced Collections 草案中定义,但是未出现在《WebDAV 顺序集协议》(RFC 3658)中。
    
    -   426 Upgrade Required
    客户端应当切换到TLS/1.0。(RFC 2817)
    
    -   449 Retry With
    由微软扩展,代表请求应当在执行完适当的操作后进行重试。
    
    -   451 Unavailable For Legal Reasons
    该请求因法律原因不可用。(RFC 7725)
    
    

    5、服务器错误

    (5、6字头)
    这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。
    这些状态码适用于任何响应方法。
    
    -   500 Internal Server Error
    服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器端的源代码出现错误时出现。
    
    -   501 Not Implemented
    服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。
    
    -   502 Bad Gateway
    作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
    
    -   503 Service Unavailable
    由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理500响应的方式处理它。
    注意:503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
    
    -   504 Gateway Timeout
    作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。
    注意:某些代理服务器在DNS查询超时时会返回400或者500错误
    
    -   505 HTTP Version Not Supported
    服务器不支持,或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
    
    -   506 Variant Also Negotiates
    由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误:被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。
    
    -   507 Insufficient Storage
    服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
    
    -   509 Bandwidth Limit Exceeded
    服务器达到带宽限制。这不是一个官方的状态码,但是仍被广泛使用。
    
    -   510 Not Extended
    获取资源所需要的策略并没有被满足。(RFC 2774)
    
    -   600 Unparseable Response Headers
    源站没有返回响应头部,只返回实体内容
    
    
    展开全文
  • 状态码

    千次阅读 2020-04-22 10:52:02
    1 如果喊完暗号之后,没有人开门,这时候隔壁老王出来了,对思彤说:”...如果我们的浏览器是将这个URL收藏了,那么当接收到301的状态码之后,浏览器应该会修改链接,修改新的URL。当然3XX的状态码不只有301。 ...

    1

     

    如果喊完暗号之后,没有人开门,这时候隔壁老王出来了,对思彤说:”铁锤搬家了,搬到了如花大街200号~“

     

    这时候思彤就要再去如花大街200号送信,这个过程就叫做永久移动(Moved Permanently),对应的HTTP状态码是301。如果我们的浏览器是将这个URL收藏了,那么当接收到301的状态码之后,浏览器应该会修改链接,修改为新的URL。当然3XX的状态码不只有301。

     

    2

     

    如果铁锤妹妹并没有搬家,而是暂时去闺蜜家住了。

     

    那么这种情况叫做临时重定向,对应的状态码为302。还有个状态码和302个功能很相似。

     

     

    3

     

    如果隔壁王大爷说,铁锤去闺蜜家住了,但是如果不是女生不给开门~

     

    这种情况中,铁锤妹妹去闺蜜家了,所以需要临时重定向,但是这种情况和302的临时重定向有什么区别呢?区别就在于请求的方式不一样。这里男生送信就是POST请求方式,女生请求就是GET请求方式。这时候的状态码就是303,表示需要临时重定向,并且必须用GET方式请求。

     

    4

     

    当然还有很多的可能性:比如说铁锤妹妹根本就没住在这~

     

    这种情况就叫做找不到系统资源,对应的HTTP状态码是大名鼎鼎的404。4XX家族还有很多状态

     

     

    5

     

    还有一些很有趣的情况,比如思彤到了铁锤妹妹家,喊错了暗号,喊成了:“天王盖地鼠~”,这时候铁锤妹妹听到这个暗号感觉外面有个神经病,这时候也不会给开门,直接让思彤走开~

     

    这种情况就是我们的协议格式出现了问题,这种情况下返回的状态码是:401

     

    6

     

    再比如,思彤到了铁锤妹妹家,喊出了口号:“天王盖地虎!”,但是今天铁锤妹妹心情不好,就是不开门,让思彤走开,无论你怎么说好话也叫不开门~(女生的心思你难猜~)

     

    这种情况就相当于是服务器拒绝了请求,HTTP状态码为:403。但是这个状态很有趣,这个状态是可以在返回体中给出拒绝的原因,但是通常情况下,这个状态码是在服务器不想给出原因的情况下使用的。所以这种情况很符合一个女生生气的情况~必然是有原因的,但是不会轻易告诉你~

     

    7

     

     我们再假设,思彤到了铁锤妹妹家,但是铁锤妹妹正在打电话,没有空理思彤~

     

    由于我们之前设定好的,邓哥相当于浏览器,铁锤妹妹相当于服务器,所以这个时候的情况就是服务器繁忙。服务器繁忙对应的状态码是503。一般在服务器负载时会返回503状态码。

     

     

    8

     

    思彤到了铁锤妹妹家,率先说出暗号:“天王盖地虎~”。铁锤妹妹答道:“邓哥一米五~”思彤:“宝塔镇河妖~”铁锤妹妹:“邓哥长不高~”对上暗号之后,思彤将信递给了铁锤妹妹~(思彤终于可以把信交给铁锤妹妹了~)但是这个时候出了个问题~铁锤妹妹不识字。。。这样就没法继续下去了。。。

     

    前面对暗号的过程,就好像是解析HTTP协议的过程。后面读信件的过程就相当于是获取出数据之后进行处理的过程。但是由于铁锤妹妹不识字没法正常的读信。这就像是服务器程序出现了错误,在读取信件的过程中发生了错误。所以这个时候报出的HTTP状态码为:500

     

    9

     

    我们假设思彤和铁锤妹妹对上了暗号,铁锤妹妹也认识字~铁锤妹妹仔读了这封信之后,给邓哥回了一封信。信的内容只有四个字:“做梦去吧~”。(经历了这么多的磨难,终于得到铁锤妹妹的回信了~)

     

    当浏览器要发送的内容被服务器端接收并处理之后,得到服务器端返回的消息。铁锤妹妹的回信就相当于是服务器端返回的信息。这样的一个来回就完成了一次HTTP请求。这个时候返回的状态码为:200

     

     

    10

     

     当思彤完成第一次送信之后,邓哥看到了铁锤妹妹的回信,觉得好桑心~于是决定再写一封信给铁锤妹妹。当思彤又一次送信给铁锤妹妹的时候,这次铁锤妹妹并没有直接回信,而是告诉思彤,还让邓哥看之前的那封信就行~(铁锤妹妹已经懒得写了~)

     

    当浏览器多次访问同一个资源的时候,如果第一次请求的结果还在缓存,还没有过期,那么在此访问这个资源的时候,为了减少网络传输的消耗,如果这个资源没有被修改过,则可以让浏览器继续使用之前缓存的内容,这样就不用再将资源发送一遍了,所以就减少了很多的网络开销。这个时候服务器返回的状态码为:304。虽然这个状态码也是3XX系列的,但是我们可以发现这个状态码看似和重定向没有什么关系~但是我们可以理解为,服务器要求浏览器将请求重定向到浏览器本身。

     

    以上的十个状态是HTTP状态码中最常见的一些状态码,也是我们Web前端初学者必须要记住的状态码。当然HTTP协议的状态码远远不止这些。我们之后讲HTTP协议的文章中,会更详细的为大家介绍HTTP协议。

     

    摘抄至渡一教育(微信公众号 腾讯课堂都可)

    展开全文
  • 网络状态码(HTTP状态码

    万次阅读 多人点赞 2017-05-25 21:32:00
    状态码的第个数字代表了响应的五种状态。 1XX系列:指定客户端应相应的某些动作,代表请求已被接受,需要继续处理。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码,所以除非在某些试验条件下,服务器禁止向...
  • HTTP状态码分类(常用HTTP状态码和HTTP状态码大全)

    千次阅读 多人点赞 2018-03-07 18:07:30
    作为个互联网开发人员对于一些服务器返回的HTTP状态的意思都必须是了如指掌的,只有将这些状态码一一弄清楚,工作中遇到的各种问题才能够处理的得心应手。好了,下面就让我们来了解一下比较常...
  • 404,500等HTTP状态码表示的含义

    千次阅读 2017-08-16 15:37:02
    1xx-信息提示这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收个或多个1xx响应。 100-继续。 101-切换协议。 2xx-成功这类状态代码表明服务器成功地接受了客户端请求。 200-确定。客户端...
  • HTTP响应状态码

    千次阅读 2019-12-04 23:02:00
    HTTP 响应状态码 ???? 状态码 ...表示目前为止一切正常, 客户端应该继续请求, 如果已完成请求则忽略. ...表示服务器应客户端升级协议的请求(Upgrade请求头)正在进行协议切换。... 默认情况下状态码为200的响...
  • HTTP返回结果状态码小结

    千次阅读 2017-07-07 15:11:13
    借助状态码,用户可以知道服务器端是正常处理了请求,还是出现了错误。 状态码中的数字的第位指定了响应类别,后两位无分类。响应类别有以下 5种。 - 1XX Informational(信息性状态码) 接收的请
  • Status Code:状态码

    千次阅读 2018-09-16 17:56:19
    状态码表示服务器的响应状态,如200代表服务器正常响应,404代表页面未找到,500代表服务器内部发生错误。在爬虫中,我们可以根据状态码来判断服务器响应状态,如状态200,则证明成功返回数据,再进行进一步的...
  • http请求状态码为返回405

    万次阅读 2019-01-07 21:53:08
    状态码为405表示请求的方式不对,请求的方式有get、post、head、put……常用的post和get。 我的报错[org.springframework.web.HttpRequestMethodNotSupportedException: Request method ‘POST’ not supported]...
  • https://www.nowcoder.com/questionTerminal/754f752b9a274bf98cb14b8bf482fd89
  • HTTP常见状态码

    千次阅读 2018-09-21 15:56:25
    HTTP常见状态码 1xx 表示消息,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。 2xx 表示成功,代表请求已被服务器接受、理解并接受。 200 服务器成功...
  • HTTP状态码说明

    千次阅读 2013-11-20 14:25:26
    一些常见HTTP状态码为: 200 – 服务器成功返回网页 404 – 请求的网页不存在 503 – 服务不可用 常见HTTP状态码大全 1xx(临时响应) 表示临时响应并需要请求者继续执行操作的状态代码。 代码 说明 http状态码 ...
  • HTTP状态码详解

    千次阅读 2016-03-31 21:09:49
    借助状态码,用户可以知道服务器端是正常处理了请求,还是出现了错误。状态码的类别 状态码 类别 说明 1XX 信息性状态码(Information) 接收的请求正在处理 2XX 成功状态码(Success) 请求正常处理完毕
  • 常用的HTTP状态码

    万次阅读 2019-04-19 14:23:32
    HTTP状态码表示HTTP协议所返回的响应的状态 100:继续 客户端应当继续发送请求。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。 101: 转换协议 在发送完这个响应最后的空行后,服务器...
  • nginx状态码详解

    万次阅读 2017-06-15 17:28:33
    nginx有以下的状态码: 200:服务器成功返回网页 403:服务器拒绝请求。 404:请求的网页不存在 499:客户端主动断开了连接。 500:服务器遇到错误,无法完成请求。 502:服务器作为网关或代理,从上游服务器...
  • FTP状态码对照

    千次阅读 2016-08-04 09:20:43
    FTP状态码: 1xx-肯定的初步答复这些状态代码指示项操作已经成功开始,但客户端希望在继续操作新命令前得到另个答复。 110重新启动标记答复。 120服务已就绪,在nnn分钟后开始。 125数据连接已打开,正在...
  • http 请求 返回状态码 405 的问题

    万次阅读 多人点赞 2019-11-15 15:46:57
    状态码为405表示请求的方式不对, 请求的方式有get、post、head、put…… 常用的post和get。 代码里面我刚刚开始的时候使用的是HttpPost发的请求,另外一边呢,刚刚开始的时候只有个get请求在那等着呢。 ...
  • 常见网页状态码

    千次阅读 2018-04-19 20:04:44
    2开头 (请求成功)表示成功处理了请求的状态代码。 200 (成功) 服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。 201 (已创建) 请求成功并且服务器创建了新的资源。 202 (已接受) 服务器已...
  • 巧记HTTP状态码

    万次阅读 2019-04-20 00:14:20
    大家都知道http状态码从1xx到5xx 总共有好几百个要想记住这些状态码并不是个容易事,本人每天看状态码,尝试各种背,发现这样并没有什么卵用,于是开启了变相图文理解记忆法方便自己记忆。 有天我们去给猫村...
  • 其实,这3位数字是HTTP状态码,用来表示网页服务器HTTP响应状态,简言之就是Web服务器用来告诉客户端发生了什么事。 1xx:信息 1XX类型的状态码是临时响应,代表着请求已经被接受,但需要继续处理,值得注意的是...
  • http状态码详解

    千次阅读 2018-03-23 10:37:40
    http的响应状态码由5段组成● 1xx,代表消息,一般是告诉客户端,请求已经收到了,正在处理● 2xx,代表请求处理成功,一般是请求收到、我明白你要的信息、请求已经处理、已经处理完成等信息● 3xx,代表重定向到...
  • 302状态码

    万次阅读 2019-07-01 16:47:54
    前言  Http 302对应生活中的真实例子,可以类比手机所对应的呼叫转移功能,... 302状态码应用的典型场景是服务器页面路径的重新规划, 比如个portal页面,换了新的域名,但是老的域名地址还有很多用户在使...
  • 1开头的http状态码表示临时响应并需要请求者继续执行操作的状态代码。 100 (继续) 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第部分,正在等待其余部分。  101 (切换协议) 请求者已要求...
  • 常见状态码及其意义

    万次阅读 2019-07-14 21:13:36
    在开发过程中前端向后端请求数据,很多时候除了200以外对其他的状态码不是很了解,今天我们就起来学习一下: 200 - - 请求成功。 304 - - 304状态码或许不应该认为是种错误,而是对客户端有缓存情况下服务端的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 623,164
精华内容 249,265
关键字:

一码元可以表示的状态为