HTTP狀態碼_HTTP Status Code_HTTP常見狀態碼查詢

2023-10-15 经常利用手冊 0

HTTP狀態碼

狀態碼含義
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 要求,那么浏览器避免主动进行重定向,除非获得用户的确认,由于要求的条件可能是以产生改变。
4001、语义有误,当前要求没法被服務器理解。除非进行点窜,不然客户端不该该反复提交这个要求。 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)
xxfseo.com