标签：

HTTP客户措施（例如浏览器），向处事器发送请求的时候必需指明请求类型（一般是GET或者POST）。如有须要，客户措施还可以选择发送其他的请求头。

    Accept：浏览器可接受的MIME类型。
    Accept-Charset：浏览器可接受的字符集。
    Accept-Encoding：浏览器能够进行解码的数据编码方法，好比gzip。Servlet能够向撑持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。
    Accept-Language：浏览器所但愿的语言种类，当处事器能够供给一种以上的语言版本时要用到。
    Accept-Ranges：可以请求网页实体的一个或者多个子范畴字段
    Authorization：授权信息，凡是呈此刻对处事器发送的WWW-Authenticate头的应答中。
    Cache-Control：指定请求和响应遵循的缓存机制
    Connection：暗示是否需要长期连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行长期连接），它就可以操作长期连接的长处，当页面包罗多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现要领是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的巨细。
    Content-Length：暗示请求动静正文的长度。
    Content-Type：请求的与实体对应的MIME信息。
    Cookie：这是最重要的请求头信息之一。
    Date：请求发送的日期和时间。
    Expect：请求的特定的处事器行为。
    From：请求发送者的email地点，由一些特殊的Web客户措施使用，浏览器不会用到它。
    Host：初始URL中的主机和端口。
    If-Match：只有请求内容与实体相匹配才有效。
    If-Modified-Since：只有当所请求的内容在指定的日期之后又颠末改削才返回它，否则返回304“Not Modified”应答。
    If-None-Match：如果内容未转变返回304代码，参数为处事器先前发送的Etag，与处事器回应的Etag对照判断是否转变。
    If-Range：如果实体未转变，处事器发送客户端丢掉的部分，否则发送整个实体。参数也为Etag。
    If-Unmodified-Since：只在实体在指按时间之后未被改削才请求告成。
    Max-Forwards：限制信息通过代办代理和网关传送的时间。
    Pragma：指定“no-cache”值暗示处事器必需返回一个刷新后的文档，即使它是代办代理处事器而且已经有了页面的本地拷贝。
    Proxy-Authorization：连接到代办代理的授权证书。
    Range：只请求实体的一部分，指定范畴。
    Referer：包罗一个URL，用户从该URL代表的页面出发访谒当前请求的页面。
    TE：客户端愿意接受的传输编码，并通知处事器接受接受尾加头信息。
    Upgrade：向处事器指定某种传输协议以便处事器进行转换（如果撑持）。
    User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
    UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，暗示屏幕巨细、颜色深度、操纵系统和CPU类型。
    Via： 通知中间网关或代办代理处事器地点，通信协议。
    Warning： 关于动静实体的警告信息。

1** 信息，处事器收到请求，需要请求者继续执行操纵.
2** 告成，操纵被告成接收并措置惩罚惩罚。
3** 重定向，需要进一步的操纵以完成请求。
4** 客户端错误，请求包罗语法错误或无法完成请求。
5** 处事器错误，处事器在措置惩罚惩罚请求的过程中产生了错误。

    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）