HTTP狀態碼詳解

問題反饋

HTTP狀態碼由三個十進制數字組成,第一個十進制數字定義了狀態碼的類型,後兩個數字沒有分類的感化。HTTP狀態碼共分爲5種類型:

分類 分類描述
1** 信息,服務器收到請求,需要請求者繼續執行操纵
2** 成功,操纵被成功领受並處理
3** 重定向,需要進一步的操纵以完成請求
4** 客戶端錯誤,請求包含語法錯誤或無法完成請求
5** 服務器錯誤,服務器在處理請求的過程中發生了錯誤
HTTP狀態碼表(版本1) 此表含狀態碼英文名稱
狀態碼 狀態碼英文名称 中文描述
1开首的狀態碼
100 Continue 繼續。客戶端應繼續其請求
101 Switching Protocols 切換協議。服務器根據客戶真个請求切換協議。只能切換到更高級的協議,例如,切換到HTTP的新版本協議
2开首的狀態碼
200 OK 請求成功。一般用于GET與POST請求
201 Created 已創建。成功請求並創建了新的資源
202 Accepted 已接管。已經接管請求,但未處理完成
203 Non-Authoritative Information 非授權信息。請求成功。但返回的meta信息不在原始的服務器,而是一個副本
204 No Content 無內容。服務器成功處理,但未返回內容。在未更新網頁的情況下,可確保浏覽器繼續顯示當前文檔
205 Reset Content 重置內容。服務器處理成功,用戶終端(例如:浏覽器)應重置文檔視圖。可通過此返回碼断根浏覽器的表單域
206 Partial Content 部分內容。服務器成功處理了部分GET請求
3开首的狀態碼
300 Multiple Choices 多種選擇。請求的資源可包含多個位置,相應可返回一個資源特点與地址的列表用于用戶終端(例如:浏覽器)選擇
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新URI,返回信息會包含新的URI,浏覽器會自動定向到新URI。今後任何新的┞穲求都應利用新的URI代替
302 Found 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續利用原有URI
303 See Other 查看其它地址。與301類似。利用GET和POST請求查看
304 Not Modified 未点窜。所要求的资本未点窜,办事器返回此狀態碼时,不会返回任何资本。客户端凡是会缓存拜候过的资本,经过过程供给一个头信息指出客户端希望只返回在指定日期以后点窜的资本
305 Use Proxy 利用代办代理。所請求的資源必須通過代办代理訪問
306 Unused 已被烧毁的HTTP狀態碼
307 Temporary Redirect 臨時重定向。與302類似。利用GET請求重定向
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 請求要求代办代理的身份認證,與401類似,但請求者應當利用代办代理進行授權
408 Request Time-out 服務器等候客戶端發送的┞穲求時間過長,超時
409 Conflict 服務器完成客戶真个PUT請求是可能返回此代碼,服務器處理請求時發生了沖突
410 Gone 客戶端請求的資源已經不存在。410分歧于404,若是資源之前有現在被永久刪除可利用410代碼,網站設計人員可通過301代碼指定資源的新位置
411 Length Required 服務器無法處理客戶端發送的不帶Content-Length的┞穲求信息
412 Precondition Failed 客戶端請求信息的先決條件錯誤
413 Request Entity Too Large 由于請求的實體過大年夜,服務器無法處理,是以拒絕請求。爲避免客戶真个連續請求,服務器可能會關閉連接。若是只是服務器暫時無法處理,則會包含一個Retry-After的響應信息
414 Request-URI Too Large 請求的URI過長(URI凡是爲網址),服務器無法處理
415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式
416 Requested range not satisfiable 客戶端請求的範圍無效
417 Expectation Failed 服務器無法滿足Expect的┞穲求頭信息
5开首的狀態碼
500 Internal Server Error 服務器內部錯誤,無法完成請求
501 Not Implemented 服務器不撑持請求的功能,無法完成請求
502 Bad Gateway 充當網關或代办代理的服務器,從遠端服務器领遭到了一個無效的┞穲求
503 Service Unavailable 由于超載或系統維護,服務器暫時的無法處理客戶真个請求。延時的長度可包含在服務器的Retry-After頭信息中
504 Gateway Time-out 充當網關或代办代理的服務器,未及時從遠端服務器獲取請求
505 HTTP Version not supported 服務器不撑持請求的HTTP協議的版本,無法完成處理
HTTP狀態碼列表(版本2) 此表的描述更詳細些
狀態碼 含義
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)
xxfseo.com