发送 PUT 或 POST 请求的客户端如果收到 100-Continue 响应而不期望它应该怎么办？答案

【问题标题】：What should do, a client who sends a PUT or POST request, if it receives 100-Continue response without expecting it?发送 PUT 或 POST 请求的客户端如果收到 100-Continue 响应而不期望它应该怎么办？
【发布时间】：2014-07-05 19:11:39
【问题描述】：

RFC 2616：https://www.rfc-editor.org/rfc/rfc2616#section-8.2.3

如果请求消息不包含具有“100-继续”期望的 Expect 请求标头字段，则源服务器不应发送 100（继续）响应。

此规则有一个例外：为了与 RFC 2068 兼容，服务器可以发送 100（继续）状态以响应不包含 Expect 请求标头字段的 HTTP/1.1 PUT 或 POST 请求。 “100-继续”的期望。其目的是最大程度地减少与未声明的等待 100（继续）状态相关的任何客户端处理延迟。

我不明白解释的目的。如果服务器已经知道它不是预期的，为什么它会发送一些东西？如果它不期望它，客户将不知道如何处理它。它别无选择，只能忽略它。但是，为什么还要麻烦发送呢？

如果客户端发送一个有body的PUT或POST请求消息，如果它在发送body之前等待确认，它将包含“Expect: 100-Continue”头，或者它会直接发送body。如果它选择直接发送，body 将在服务器发送“100-Continue”响应之前发送，如果客户端在没有任何内容可发送时收到该响应，它会做什么？

我还阅读了有关 100-Continue 响应的其他问题，但我没有得到任何答案...

【问题讨论】：

标签： http

【解决方案1】：

RFC 2068 不包含“Expect: 100-continue”标头。接收 HTTP 1.1 请求的服务器需要在接收请求正文之前发送 100-Continue 响应：

从
收到符合这些要求的方法后 HTTP/1.1（或更高版本）客户端，HTTP/1.1（或更高版本）服务器必须以 100（继续）状态响应并继续从
输入流，或以错误状态响应。

后来，RFC 2616 包含了 Expect 标头，但允许服务器为之前实现并可能正在等待它的客户端发送 100-Continue 响应。

【讨论】：