The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
Requirements for HTTP/1.1 clients:
- If a client will wait for a 100 (Continue) response before
sending the request body, it MUST send an Expect request-header
field (section 14.20) with the "100-continue" expectation.
- A client MUST NOT send an Expect request-header field (section
14.20) with the "100-continue" expectation if it does not intend
to send a request body.
Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100- continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
Requirements for HTTP/1.1 origin servers:
- Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response. If it responds with a final status
code, it MAY close the transport connection or it MAY continue
to read and discard the rest of the request. It MUST NOT
perform the requested method if it returns a final status code.
- An origin server SHOULD NOT send a 100 (Continue) response if
the request message does not include an Expect request-header
field with the "100-continue" expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0
(or earlier) client. There is an exception to this rule: for
compatibility with RFC 2068, a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
continue" expectation. This exception, the purpose of which is
to minimize any client processing delays associated with an
undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version value.
- An origin server MAY omit a 100 (Continue) response if it has
already received some or all of the request body for the
corresponding request.
- An origin server that sends a 100 (Continue) response MUST
ultimately send a final status code, once the request body is
received and processed, unless it terminates the transport
connection prematurely.
- If an origin server receives a request that does not include an
Expect request-header field with the "100-continue" expectation,
the request includes a request body, and the server responds
with a final status code before reading the entire request body
from the transport connection, then the server SHOULD NOT close
the transport connection until it has read the entire request,
or until the client closes the connection. Otherwise, the client
might not reliably receive the response message. However, this
requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from
badly broken client implementations.
Requirements for HTTP/1.1 proxies:
- If a proxy receives a request that includes an Expect request-
header field with the "100-continue" expectation, and the proxy
either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version of the next-hop
server, it MUST forward the request, including the Expect header
field.
- If the proxy knows that the version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status.
- Proxies SHOULD maintain a cache recording the HTTP version
numbers received from recently-referenced next-hop servers.
- A proxy MUST NOT forward a 100 (Continue) response if the
request message was received from an HTTP/1.0 (or earlier)
client and did not include an Expect request-header field with
the "100-continue" expectation. This requirement overrides the
general rule for forwarding of 1xx responses (see section 10.1).
转自:http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
不甚理解。
分享到:
相关推荐
### HTTP状态码大全详解 HTTP协议作为Web应用的基础通信协议之一,在互联网中扮演着至关重要的角色。它定义了一系列的状态码来表示服务器响应客户端请求的状态。本文将详细介绍HTTP状态码的各种类型及其含义,帮助...
"易语言取HTTP状态码源码"这个压缩包文件很可能是提供了使用易语言编写的一个程序或库,用于获取HTTP请求的响应状态码。易语言是一种中文编程语言,设计目标是使编程变得简单,适合初学者和专业人士。通过易语言,...
在开发过程中,理解和正确使用这些HTTP状态码至关重要,它们可以帮助调试问题,确保客户端与服务器之间的通信顺畅。在Java的Servlet环境中,可以使用HttpServletResponse类中的静态常量如SC_OK、SC_CREATED等来设置...
### 常见HTTP状态码详解 #### 一、引言 HTTP状态码是Web开发与维护中的一个重要组成部分,它们不仅对于网站管理者至关重要,对于理解客户端与服务器间交互过程也十分关键。本文将深入探讨常见HTTP状态码的意义及...
### HTTP状态码详解 HTTP状态码是Web服务器与客户端(如浏览器)通信的重要组成部分,用于指示请求的结果。...每个状态码都有其特定的含义和应用场景,正确理解和使用HTTP状态码对于开发健壮的网络应用至关重要。
### HTTP状态码详解 ...本篇将详细介绍各种HTTP状态码的意义及其应用场景。...在实际开发过程中,合理使用HTTP状态码能够帮助开发者更准确地表达客户端与服务器之间交互的结果,提高系统的可用性和用户体验。
在易语言中,获取HTTP状态码通常涉及到网络模块的使用,可能需要使用到如“创建HTTP连接”,“发送HTTP请求”,“接收HTTP响应数据”等命令。程序会通过发送HTTP请求到指定URL,然后解析服务器返回的响应数据,从中...
选择正确的HTTP状态码对于网站和API开发者来说是非常重要的,因为它不仅帮助开发者和使用者理解请求响应的性质,还指导客户端进行适当的错误处理和后续行为。状态码的正确使用可以提高开发效率、增强用户体验,并且...
### HTTP状态码详解 HTTP(超文本传输协议)是用于从Web服务器传输超文本到本地浏览器的传送协议。HTTP状态码是由三个十进制数字组成的响应状态代码,它定义了客户端请求服务器后的结果状态。HTTP状态码的第一位...
HTTP状态码用于告知客户端请求的状态。这些状态码分为五类:1xx(信息性响应)、2xx(成功响应)、3xx(重定向响应)、4xx(客户端错误)以及5xx(服务器错误)。接下来,我们将逐一探讨这些状态码的具体含义及其在...
了解HTTP状态码对于Web开发者来说至关重要,它可以帮助调试和优化网站性能,确保用户和搜索引擎爬虫能够正确、高效地访问和索引网页。在遇到重定向问题时,应尽量避免过多的重定向链,以免影响用户体验和搜索引擎的...
HTTP状态码是HTTP协议中用于表示客户端与服务器交互情况的三位数字编码,它们反映了服务器对客户端请求的响应状态。理解HTTP状态码对于诊断网络问题、优化网页性能以及调试API接口至关重要。以下是对常见HTTP状态码...
HTTP状态码是网络通信中用来标识客户端与服务器之间交互情况的重要信息。这些状态码由三位数字组成,分为五类,分别表示不同的响应状态。以下是各分类的详细解释: 1xx(临时响应):这些状态码表示服务器正在处理...
例如,状态码100(Continue)表示客户端可以继续发送请求的主体部分,如果客户端在请求头中使用了"Expect: 100-continue"。 101:切换协议 状态码101(Switching Protocols)意味着服务器将遵循请求头中的Upgrade...
HTTP状态码是Web服务器向客户端发送的用于表示HTTP请求结果的三位数字代码,它反映了服务器处理请求的不同状态。这些状态码被分为五类,每类都代表特定的意义和响应情况。 1xx(临时响应):这类状态码表示服务器...
- **410 Gone**: 如果请求的资源一去不复返了,应当使用410状态码。 - **411 Length Required**: 服务器拒绝在没有定义Content-Length头的情况下接受请求。 - **412 Precondition Failed**: 服务器在验证在请求的头...
HTTP状态码是网络开发者在构建和维护Web应用时必须熟知的重要元素。它们是服务器与客户端之间通信的关键,用于指示请求是否成功以及发生何种问题。HTTP状态码由三位数字组成,分为五类,每类代表不同的含义。 1xx...
### HTTP状态码详解 HTTP状态码是Web服务器与客户端(如浏览器或爬虫程序)通信过程中,用于描述请求结果的一种标准化编码方式。当客户端向服务器发送请求时,服务器会返回一个HTTP状态码来告知客户端其请求的状态...
本文将深入探讨易语言中的HTTP状态码获取方法,以及其在编程实践中的应用。 易语言,是中国本土的一款中文编程语言,它以“易”为设计理念,旨在降低编程难度,让普通用户也能进行软件开发。在易语言中处理HTTP请求...