HTTP1.1访问网页的各个状态代码如下所述，包括可以遵循哪些方法以及响应中需要的任何元信息的描述。
1信息1xx
此类状态码表示临时响应，仅由状态行和可选标头组成，并由空行终止。此类状态代码没有必需的标题。由于HTTP / 1.0没有定义任何1xx状态代码，因此除实验条件外，服务器不得向HTTP / 1.0客户端发送1xx响应。
客户端必须准备在定期响应之前接受一个或多个1xx状态响应，即使客户端不期望100（继续）状态消息。意外的1xx状态响应可能被用户代理忽略。
代理必须转发1xx响应，除非代理与其客户端之间的连接已关闭，或者除非代理本身请求生成1xx响应。（例如，如果a
代理在转发请求时添加“Expect：100-continue”字段，则不需要转发相应的100（Continue）响应。）
1.1 100继续
客户应该继续请求。该临时响应用于通知客户端请求的初始部分已被接收，并且尚未被服务器拒绝。客户端应继续发送请求的其余部分，如果请求已经完成，则忽略该响应。服务器必须在请求完成后发送最终响应。有关使用和处理此状态代码的详细讨论，请参见第8.2.3节。
1.2 101切换协议
服务器通过升级消息头字段（第14.42节）了解并愿意遵守客户端的请求，以便更改此连接上使用的应用协议。服务器将在终止101响应的空行之后立即将协议切换到由响应的“升级”头字段定义的协议。
只有在有利的情况下才应该切换协议。例如，切换到较新版本的HTTP对于旧版本是有利的，并且当递送使用这种特征的资源时，切换到实时同步协议可能是有利的。
2成功2xx
此类状态码表示客户端的请求已成功接收，理解并被接受。
2.1 200 OK
请求成功。与响应一起返回的信息取决于请求中使用的方法，例如：
GET：响应中发送对应于所请求资源的实体；
HEAD：与所请求的资源相对应的实体头部字段在没有任何消息体的响应中发送；
POST：一个描述或包含动作结果的实体;
TRACE：包含终端服务器接收到的请求消息的实体。
2.2创建201
该请求已经实现，并导致创建了一个新的资源。新创建的资源可以由响应实体中返回的URI引用，由位置头字段给出的资源最具体的URI。响应应该包括一个包含资源特征和位置的实体，用户或用户代理可以从该列表中选择最合适的一个。实体格式由Content-Type头字段中指定的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果该操作无法立即执行，服务器应该以202（Accepted）响应来响应。
201响应可以包含ETag响应头字段，指示刚创建的请求变体的实体标签的当前值，请参见第4.19。
2.3 202接受
该请求已被接受处理，但处理尚未完成。该请求可能或可能不会最终被执行，因为在处理实际发生时可能不允许。没有可以从异步操作（如此）重新发送状态代码的功能。
202回应是故意不提交的。其目的是允许服务器接受一些其他进程的请求（可能是每天只运行一次的面向批次的进程），而不要求用户代理与服务器的连接持续到进程完成为止。该响应返回的实体应该包括请求的当前状态的指示，以及指向状态监视器的指针，或者用户何时可以期望该请求被满足的估计。
2.4 203非授权信息
实体头中返回的元信息不是从源服务器可用的确定集，而是从本地或第三方副本收集的。所呈现的集合可以是原始版本的子集或超集。例如，包括有关资源的本地注释信息可能会导致源服务器已知的元信息的超集。不需要使用此响应代码，仅当响应为200（OK）时才适用。
2.5 204无内容
服务器已经满足了请求，但不需要返回一个实体，并且可能希望返回更新的元信息。响应可以包括实体标题形式的新的或更新的元信息，如果存在，则应该与所请求的变体相关联。
如果客户端是用户代理，则不应将其文档视图与导致请求发送的文档视图进行更改。该响应主要是为了允许进行动作的输入，而不会导致更改用户代理的活动文档视图，尽管任何新的或更新的元信息应该应用于当前在用户代理的活动视图中的文档。
204响应不能包括消息体，因此总是在头字段之后的第一个空行终止。
2.6 205重置内容
服务器已满足请求，用户代理应该重置导致发送请求的文档视图。该响应主要旨在允许通过用户输入进行动作的输入，随后清除输入的形式，使得用户可以容易地启动另一个输入动作。答复不能包括实体。
2.7 206部分内容
服务器已经满足了资源的部分GET请求。请求必须包括一个指示期望范围的范围标题字段（第14.35节），并且可以包括一个If-Range头字段（第14.27节）来使请求成为条件。
响应必须包括以下标题字段：
- 内容范围标题字段（第14.16节）
该响应包含的范围，或多部分/ byteranges
Content-Type包含每个部分的Content-Range字段。如果一个
Content-Length头字段存在于响应中
值必须匹配传输的OCTET的实际数量
消息体。
- 日期
- ETag和/或Content-Location，如果标题将被发送
在200响应相同的请求
- 如果字段值可能，则到期，Cache-Control和/或Vary
不同于以前在任何响应中发送的
变体
如果206响应是使用强缓存验证器的If-Range请求的结果（见第13.3.3节），响应应不包括其他实体头。如果响应是使用弱验证器的If-Range请求的结果，则响应不能包括其他实体头; 这可以防止缓存的实体和更新的头文件之间的不一致。否则，响应必须包括所有返回的实体标题，并返回200（OK）响应到相同的请求。
如果ETag或Last-Modified头部不完全匹配，则缓存不得将206响应与其他先前缓存的内容相组合，请参见第5.4节。不支持Range和Content-Range标头的缓存不能缓存206（Partial）响应。
3重定向3xx
此类状态码表示用户代理需要采取进一步的操作才能完成请求。当且仅当第二个请求中使用的方法是GET或HEAD时，所需的操作可以由用户代理执行，而不与用户交互。客户端应该检测无限重定向循环，因为这样的循环为每个重定向生成网络流量。
注意：此规范的以前版本推荐最多五个重定向。内容开发者应该知道这个局限性。
3.1 300多项选择
所请求的资源对应于一组表示中的任何一个，每个具有其自己的特定位置，并且正在提供代理驱动的协商信息（第12节），使得用户（或用户代理）可以选择优选的表示并将其重定向请求到该位置。
除非是HEAD请求，响应应该包括一个包含资源特征列表和位置的实体，用户或用户代理可从中选择最合适的一个。实体格式由Content-Type头域中指定的媒体类型指定。取决于格式和功能用户代理，选择最合适的选择可以自动执行。然而，本规范并没有定义这种自动选择的任何标准。
如果服务器有一个首选的表示方式，它应该在Location字段中包含该表示的特定URI; 用户代理可以使用位置字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。
3.2 301永久移动
所请求的资源已经被分配了一个新的永久URI，并且任何将来对该资源的引用应该使用返回的URI之一。具有链接编辑功能的客户端应该可以自动将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。
新的永久URI应该由响应中的位置字段给出。除非请求方法是HEAD，响应的实体应该包含一个带有超链接到新URI的超文本短信。
如果为了响应除GET或HEAD之外的请求而接收到301状态码，用户代理不得自动重定向请求，除非用户可以确认，否则可能会更改发出请求的条件。
注意：在收到301状态代码后自动重定向POST请求时，一些现有的HTTP / 1.0用户代理将错误地将其更改为GET请求。
3.3 302发现
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，所以客户端应该继续使用Request-URI来应对未来的请求。如果由Cache-Control或Expires标头字段指示，此响应只能缓存。
临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，响应的实体应该包含一个带有超链接到新URI的超文本短信。
如果响应于除GET或HEAD之外的请求而接收到302状态码，用户代理不得自动重定向请求，除非用户可以确认，否则可能会更改发出请求的条件。
注意：RFC 1945和RFC 2068指定客户端不允许更改重定向请求上的方法。然而，大多数现有的用户代理实现将302看作是一个303响应，在Location字段值上执行GET，而不管原始请求方法如何。已经为希望明确清楚客户端预期哪种反应的服务器添加了状态代码303和307。
3.4 303见其他
对请求的响应可以在不同的URI下找到，并且应该使用该资源上的GET方法来检索。此方法主要用于允许输出POST激活的脚本将用户代理重定向到所选资源。新的URI不是原始请求的资源的替代参考。303响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。
响应中的位置字段应该给出不同的URI。除非请求方法是HEAD，响应的实体应该包含一个带有超链接到新URI的超文本短信。
注意：许多HTTP / 1.1之前的用户代理不了解303的状态。当与这样的客户端的互操作性是关注时，可以使用302状态代码，因为大多数用户代理对302所述的响应做出反应，如这里对于303所述。
3.5 304未修改
如果客户端执行了条件GET请求，并且允许访问，但是该文档尚未被修改，则服务器应该使用该状态代码进行响应。304响应不能包含消息体，因此总是在头字段之后的第一个空行终止。
响应必须包括以下标题字段：
- 日期，除非第14.18.1条规定其不作为
如果无时钟源服务器遵守这些规则，并且代理和客户端将自己的日期添加到任何没有接收到的响应（如[RFC 2068]第14.19节已经指定）），缓存将正常运行。
- ETag和/或Content-Location，如果标题将被发送
在200响应相同的请求
- 如果字段值可能，则到期，Cache-Control和/或Vary
不同于以前在任何响应中发送的变体
如果条件GET使用强缓存验证器（见第3.3节），响应应不包括其他实体头。否则（即，条件GET使用弱验证器），响应不能包括其他实体头; 这可以防止缓存的实体和更新的头文件之间的不一致。如果304响应指示当前未缓存的实体，则高速缓存必须忽略该响应并重复该请求而不具有条件。如果缓存使用接收到的304响应来更新缓存条目，则高速缓存务必更新该条目以反映响应中给出的任何新的字段值。
3.6 305使用代理
所请求的资源必须通过位置字段给出的代理进行访问。位置字段给出代理的URI。收件人预计将通过代理重复此单一请求。305响应必须只能由源服务器生成。
注意：RFC 2068并不清楚，305旨在重定向一个请求，并仅由源服务器生成。不遵守这些限制会带来重大安全后果。
3.7 306（未使用）
306状态码在规范的先前版本中使用，不再使用，代码被保留。
3.8 307临时重定向
请求的资源暂时驻留在不同的URI下。由于重定向可能有时被改变，所以客户端应该继续使用Request-URI来应对未来的请求。如果由Cache-Control或Expires标头字段指示，此响应只能缓存。
临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个具有超链接到新URI的短超文本注释，因为许多HTTP / 1.1之前的用户代理不了解307状态。因此，该笔记应包含用户在新URI上重复原始请求所需的信息。
如果响应于GET或HEAD之外的请求接收到307状态码，用户代理不得自动重定向请求，除非用户可以确认，否则可能会更改发出请求的条件。
4客户端错误4xx
4xx类的状态代码适用于客户端似乎有错误的情况。除了响应HEAD请求之外，服务器应该包含一个包含错误情况说明的实体，以及它是一个临时的还是永久的。这些状态码适用于任何请求方式。用户代理应该向用户显示任何包含的实体。
如果客户端正在发送数据，则在服务器关闭输入连接之前，使用TCP的服务器实现应该小心，以确保客户端确认收到包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，则服务器的TCP堆栈将向客户端发送重置数据包，这可能会擦除客户端未确认的输入缓冲区，然后才能被HTTP应用程序读取和解释。
4.1 400错误请求
由于格式错误，服务器无法理解该请求。客户端不要重复请求而不进行修改。
4.2 401未经授权
该请求需要用户认证。响应必须包括一个WWW-Authenticate头字段（第14.47节），其中包含适用于所请求资源的挑战。客户端可以使用合适的授权头域（第14.8节）重复该请求。如果请求已经包含授权凭据，那么401响应表明这些凭据已被拒绝授权。如果401响应包含与先前响应相同的挑战，并且用户代理已经尝试至少进行一次认证，则应该向用户呈现在响应中给出的实体，因为该实体可能包括相关的诊断信息。HTTP访问认证在“HTTP认证：
4.3 402付款需要
此代码保留供将来使用。
4.4 403禁止
服务器了解该请求，但拒绝履行该请求。授权不会有帮助，请求不能重复。如果请求方法不是HEAD，并且服务器希望公开为什么请求尚未实现，则应该描述拒绝实体的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）。
4.5 404未找到
服务器没有找到与Request-URI匹配的任何内容。没有指示条件是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧的资源永久不可用，并且没有转发地址，则应该使用410（Gone）状态码。当服务器不希望明确地显示请求被拒绝的原因，或者没有其他响应适用时，通常使用此状态代码。
4.6 405不允许的方法
由Request-URI标识的资源不允许在Request-Line中指定的方法。响应必须包括一个包含所请求资源的有效方法列表的Allow标头。
4.7 406不可接受
由请求标识的资源仅能够根据请求中发送的接受头来生成内容特征不可接受的响应实体。除非是HEAD请求，响应应该包括一个包含可用实体特征和位置列表的实体，用户或用户代理可从中选择最合适的一个。实体格式由Content-Type头字段中指定的媒体类型指定。根据用户代理的格式和功能，可以自动执行最合适的选择。然而，本规范并没有定义这种自动选择的任何标准。
注意：允许HTTP / 1.1服务器返回根据请求中发送的接受头不能接受的响应。在某些情况下，甚至可能发送406响应更为可取。鼓励用户代理检查传入响应的标题，以确定是否可以接受。如果响应不可接受，则用户代理应该暂时停止接收更多的数据，并询问用户对进一步的操作做出决定。
4.8 407需要代理验证
此代码类似于401（未经授权），但表示客户端必须首先使用代理身份验证自身。代理务必返回一个代理身份验证头域（第14.33节），其中包含适用于所请求资源的代理的挑战。客户端可以使用合适的代理授权头域重复该请求（第14.34节）。HTTP访问认证在“HTTP认证：基本和摘要访问认证” [43]中进行了说明。
4.9 408请求超时
客户端在服务器准备等待的时间内没有产生请求。客户可以随时重复请求而不进行修改。
4.10 409冲突
由于与资源的当前状态冲突，无法完成该请求。只有在预期用户可能能够解决冲突并重新提交请求的情况下，才允许使用此代码。响应机构应该包括足够的
信息供用户识别冲突的根源。理想情况下，响应实体将包括足够的信息供用户或用户代理解决问题; 然而，这可能是不可能的，不是必需的。
冲突最有可能发生在响应PUT请求。例如，如果正在使用版本控制，并且包含PUT的实体更改为与早期（第三方）请求所做的冲突的资源相冲突，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能包含由响应Content-Type定义的格式的两个版本之间的差异列表。
4.11 410 Gone
所请求的资源在服务器上不再可用，并且没有转发地址是已知的。这种情况有望被认为是永久性的。具有链接编辑功能的客户端应该在用户批准后删除对Request-URI的引用。如果服务器不知道，或者无法确定条件是否永久，则应该使用状态代码404（未找到）。除非另有说明，否则此响应是可缓存的。
410响应主要旨在通过向收件人通知资源有意不可用并且服务器所有者希望删除该资源的远程链接来帮助Web维护任务。这种事件对于有限时间，促销服务以及属于不再在服务器站点工作的个人的资源是常见的。没有必要将所有永久不可用的资源标记为“已经”或将标记保持在任何时间长度 - 这由服务器所有者决定。
4.12 411需要长度
服务器拒绝接受请求而没有定义的Content-Length。如果客户端在请求消息中添加了包含消息体长度的有效Content-Length头字段，则客户端可以重复该请求。
4.13 412前提条件失败
在服务器上测试的一个或多个请求头字段中给出的前提条件被评估为false。该响应代码允许客户端在当前资源元信息（头字段数据）上放置前提条件，从而防止所请求的方法被应用于除预期的资源之外的资源。
4.14 413请求实体太大
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的请求实体。服务器可能会关闭连接，以防止客户端继续请求。如果条件是临时的，则服务器应该包括一个Retry-After头域，以指示它是临时的，并且在什么时候客户端可以再次尝试。
4.15 414请求URI太长
服务器拒绝服务请求，因为Request-URI比服务器愿意解释更长。当客户端已经下降到重定向的URI“黑洞”（例如，指向重定向的URI前缀）时，客户端将POST请求正确转换为具有长查询信息的GET请求时，可能会发生这种罕见的情况本身的后缀），或者服务器受到试图利用固定长度缓冲区中存在的某些服务器中存在的安全漏洞的客户端进行攻击，以读取或操作Request-URI。
4.16 415不支持的介质类型
服务器拒绝服务请求，因为请求的实体是被请求的方法所请求资源不支持的格式。
4.17 416请求范围不满意
如果请求包含Range请求头字段（第14.35节），服务器应该返回一个具有该状态码的响应，并且此字段中的范围说明符值中的任何一个都不与所选资源的当前范围重叠，并且请求没有包括一个If-Range请求头字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位数大于所选资源的当前长度。）
当返回一个字节范围请求的状态码时，响应应该包括一个Content-Range entity-header字段，指定所选资源的当前长度（见第14.16节 ）。此响应不得使用multipart / byteranges内容类型。
4.18 417期望失败
该服务器无法满足Expect请求头字段（见第14.20节）中给出的期望，或者如果服务器是代理服务器，则服务器具有明确的证据表明下一跳服务器无法满足该请求。
5服务器错误5xx
以数字“5”开头的响应状态代码表示服务器知道它已经发生错误或不能执行请求的情况。除了响应HEAD请求之外，服务器应该包含一个包含错误情况说明的实体，以及它是一个临时的还是永久的。用户代理应该向用户显示任何包含的实体。这些响应代码适用于任何请求方式。
5.1 500内部服务器错误
服务器遇到意外的情况，阻止它满足请求。
5.2 501未实施
服务器不支持完成请求所需的功能。当服务器无法识别请求方法并且不能支持任何资源时，这是适当的响应。
5.3 502坏网关
作为网关或代理的服务器在尝试完成请求时从其访问的上游服务器接收到无效响应。
5.4 503服务不可用
由于服务器的临时重载或维护，服务器目前无法处理该请求。这意味着这是一个暂时的条件，这将在一段延迟之后得到缓解。如果知道，延迟的长度可以在Retry-After报头中指示。如果没有提供Retry-After，客户端应该处理响应，就像500次响应一样。
注意：503状态代码的存在并不意味着服务器在重载时必须使用它。有些服务器可能希望简单地拒绝连接。
5.5 504网关超时
作为网关或代理服务器的服务器没有从尝试完成访问所需的URI（例如HTTP，FTP，LDAP）或其他辅助服务器（例如DNS）指定的上游服务器收到及时的响应请求。
5.6 505不支持HTTP版本
服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。服务器表示它不能或不愿意使用与客户端相同的主要版本来完成请求，如第3.1节所述 ，而不是此错误消息。响应应该包含一个描述为什么不支持该版本以及该服务器支持哪些其他协议的实体。