HTTP 1.1 Status Code Definitions

最新推荐文章于 2022-07-07 09:54:02 发布

javaUTU

最新推荐文章于 2022-07-07 09:54:02 发布

阅读量1.2k

点赞数

CC 4.0 BY-SA版权

分类专栏：译文文章标签：服务器 exception protocols standards authentication conflict

本文链接：https://blog.youkuaiyun.com/javaUTU/article/details/6840277

译文专栏收录该内容

0 篇文章

订阅专栏

本文详细解析了HTTP 1.1协议中的状态码定义，包括1xx信息性状态码和2xx成功状态码，特别是100 Continue和200 OK的用法。介绍了客户端、源服务器和代理服务器在处理HTTP/1.1请求时的规则，以及对100 (Continue)状态码的使用要求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

rfc 2616 http://www.rfc-editor.org/rfc/rfc2616.txt

百度百科： http://baike.baidu.com/view/1790469.htm

6.1 Status-Line

response消息的第一行就是status-line,包含：http版本信息，状态码，以及该状态码相关的文本化短语，由空格隔开：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reson Phrase

3位数的状态码用于响应客户端的不同request。详细讨论见章节10

状态码第一位用来标识状态码的分类：

- 1xx: Informational - Request received, continuing process

      - 2xx: Success - The action was successfully received,
        understood, and accepted

      - 3xx: Redirection - Further action must be taken in order to
        complete the request

      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled

      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request

Status-Code    =
            "100"  ; Section 10.1.1: Continue
          | "101"  ; Section 10.1.2: Switching Protocols
          | "200"  ; Section 10.2.1: OK
          | "201"  ; Section 10.2.2: Created
          | "202"  ; Section 10.2.3: Accepted
          | "203"  ; Section 10.2.4: Non-Authoritative Information
          | "204"  ; Section 10.2.5: No Content
          | "205"  ; Section 10.2.6: Reset Content
          | "206"  ; Section 10.2.7: Partial Content
          | "300"  ; Section 10.3.1: Multiple Choices
          | "301"  ; Section 10.3.2: Moved Permanently
          | "302"  ; Section 10.3.3: Found
          | "303"  ; Section 10.3.4: See Other
          | "304"  ; Section 10.3.5: Not Modified
          | "305"  ; Section 10.3.6: Use Proxy
          | "307"  ; Section 10.3.8: Temporary Redirect
          | "400"  ; Section 10.4.1: Bad Request
          | "401"  ; Section 10.4.2: Unauthorized
          | "402"  ; Section 10.4.3: Payment Required
          | "403"  ; Section 10.4.4: Forbidden
          | "404"  ; Section 10.4.5: Not Found
          | "405"  ; Section 10.4.6: Method Not Allowed
          | "406"  ; Section 10.4.7: Not Acceptable



Fielding, et al.            Standards Track                    [Page 40]

RFC 2616                        HTTP/1.1                       June 1999


          | "407"  ; Section 10.4.8: Proxy Authentication Required
          | "408"  ; Section 10.4.9: Request Time-out
          | "409"  ; Section 10.4.10: Conflict
          | "410"  ; Section 10.4.11: Gone
          | "411"  ; Section 10.4.12: Length Required
          | "412"  ; Section 10.4.13: Precondition Failed
          | "413"  ; Section 10.4.14: Request Entity Too Large
          | "414"  ; Section 10.4.15: Request-URI Too Large
          | "415"  ; Section 10.4.16: Unsupported Media Type
          | "416"  ; Section 10.4.17: Requested range not satisfiable
          | "417"  ; Section 10.4.18: Expectation Failed
          | "500"  ; Section 10.5.1: Internal Server Error
          | "501"  ; Section 10.5.2: Not Implemented
          | "502"  ; Section 10.5.3: Bad Gateway
          | "503"  ; Section 10.5.4: Service Unavailable
          | "504"  ; Section 10.5.5: Gateway Time-out
          | "505"  ; Section 10.5.6: HTTP Version not supported
          | extension-code

      extension-code = 3DIGIT
      Reason-Phrase  = *<TEXT, excluding CR, LF>

http状态码是可扩展的，也就是说我们定制的客户端客户端程序可以自定义一些状态码。我们定义的客户端程序应该理解5类状态码鸽子的含义，一旦接受到不能理解的状态码，将其等同为该类的x00状态码。例如遇到未知的431，将其等同为400.此时，用户嗲里应该将随同response返回的entity展现给用户，因为这些entity可能包含人类可读的信息，而这些信息将解释这些不可理解的状态码，如431.

8.2.3 Use of the 100 (Continue) Status

这个状态码的作用是让客户端判断源服务器是否希望接受紧跟着请求头(request header)的请求体(request body)。也就是说，客户端在发出一个包含标明Exception字段的请求头之后，会根据服务器返回的respose的状态码判断，同一个请求的额请求体是否还要发送过去。

Requirements for HTTP/1.1 clients:

--- 一个客户端如果决定暂不发送请求体，而等待服务器返回100的状态码后再发送，就必须先发送一个包含 "100-continue"的Exceptin报头的请求过去。参见本协议14.20

---如果客户端不决定发送请求体，就绝不要发送一个包含Exception 值为“100-continue“的请求。

因为旧http协议依然在使用，所以，http1.1对客户端发送了“ExceptionP: 100-continue”而没有收到417/100的状态码reponse时的行为定义是模糊的。所以，如果客户端迟迟等不到服务器段的100状态码response，也不要一直等下去，可以直接发送请求体。

Requirements for HTTP/1.1 origin servers:

---一旦收到一个包含“Exception： 100-continue”的请求，源服务器要不返回一个100的状态码回应然后继续从输入流中读数据，要不用一个终止状态码结束。源服务器不要在还没有发送100状态码的响应前就开始等待请求体发过来。如果，是返回一个终止状态码，服务器的行为就多种多样了，可能是关闭连接，可能是继续读并求无视掉该请求的其他部分，如果服务器选择返回终止状态码，它的因为一定不能是执行被请求的方法。

---在客户端没有显示添加“Exceptin:100-continue”报头的请求时，服务器不应该发送100状态码的响应，对不支持http1.1的客户端，也不应该发送这个响应。但有个特例：为了和RFC 2068兼容，在HTTP/1.1 PUT或者POST请求中，即使请求中没有“Exception: 100-continue”字段，服务器也可能发送100状态码的响应，因为这样可以最小化客户端未申报的对100状态码的回应的等待。

---如果服务器已经接受到了一些或者所有的请求体，就应该再发送100状态码响应了。

---除非过早的断开了连接，那么源服务器在接收并处理完请求体的时候必须返回一个终止状态的回应。

---如果服务器正在处理一个包含请求体的请求，这个请求中并没有加上“Excpetin : 100-continue”的报头，在服务器读完整个请求体之前就返回一个终止状态码码的回应，服务器不应该关闭连接，除非等到服务器读完整个请求，或者除非客户端先自己关闭连接。否则，客户端就无法接收到可靠的响应消息。然而，这条需求不应该被解释成为了保护服务原理拒绝服务的攻击，也不是为了防止垃圾的客户端实现。

Requirements for HTTP/1.1 proxies:

---如果代理服务器收到一个包含“Exception: 100-continue”报头的请求，在不知道吓一跳的服务器是否兼容http1.1或更高版本时，或者根本不知道下一跳服务器的http协议版本兼容性，就必须转发请求，并将原有的Exception头包含进去。

---如果代理服务器能看到下一跳的服务器的http兼容性是1.0乃至更低，一定不能转发请求，必须代理服务器自己响应一个417的响应。

---代理服务器对最近应用的下一跳的服务器的http兼容性，应该做一个缓存记录。

---如果客户端的http兼容性是1.0或更低，代理服务器不应该转发100状态码的响应，也不应该在这个低版本客户端发过来的请求中插入“Exception：100-continue“报头。这条需求凌驾于（overrides）之前的一般性规则之上（见章节 10.1）

10、状态码定义

下面每个状态码的描述都包含它支持的request方法，还有在reponse中设置这个状态码时需要的其它元信息。有时，服务器在不知道请求体内容的情况下就断然拒绝接受，是不合合适也没效率的。

10.1 Informatinal 1xx

这类状态码是临时的response，仅仅包含status-line、optional headers并被空白行结束。对于这类状态码，没有什么header是必须出现的。因为HTTP1.0没有定义任何该类状态码，服务器一定不可以发送该类的响应给http1.0 客户端，除非你只是想实验一下。

在一个普通的response之前，客户端的默认状态是准备好接受一个或多个该类的response，即使客户端并没有发送请求要获得服务器的此类响应。也就是说，客户端应该随时准备接受此类的response。有时该类的response会被用户代理忽略。

代理服务器必须转发该类的response，除非在代理服务器和客户端之间的连接已经被关闭了，或者除非只是代理服务器自己发起的该类请求。也就是说，代理服务器总是会将服务器过来的该类response转发给客户端。（例如，代理服务器在转发的请求中加上100-continue的Exception报头，这是就无需转发响应的该类response了）。