http 1.1 rfc：在持续连接期望100-continue之后的错误最终状态代码

Question

HTTP 1.1 RFC说：

  

不需要发送100-continue期望的客户端         等待任何特定的时间;这样的客户可以继续         即使尚未收到回复，也会发送邮件正文。

相同的RFC：

  

在阅读之前使用最终状态代码进行响应的服务器         整个消息体应该在该响应中表明是否存在         打算关闭连接或继续阅读和丢弃         请求消息（见Section 6.6 of [RFC7230]）。

每个人都知道HTTP1.1允许在同一TCP连接中发出多个请求。

如果服务器在响应错误的最终状态代码并且＃34;请求：100-continue＆＃34;头：

• 如果服务器将读取剩余的＆＃34;内容长度＆＃34;来自流和的字节 丢弃它们，客户端不会发送正文 - 而不是正在进行的请求 客户端将被完全丢弃或被服务器损坏。
• 如果服务器将读取剩余的＆＃34;内容长度＆＃34;来自流和的字节 丢弃它们，客户端将发送正文 - 比使用100-continue是没用的。
• 如果服务器无法读取并丢弃剩余的＆＃34;内容长度＆＃34;来自流和客户端的字节将发送正文 - 在最好的情况下，服务器将响应400错误请求，客户端将收到该响应作为对其正在进行的请求的响应。
• 如果服务器无法读取并丢弃剩余的＆＃34;内容长度＆＃34;来自流和客户端的字节不会发送正文 - 会话将继续正确，但可能你不会那么幸运。

所以似乎根据标准，如果服务器或客户端在请求发送/接收错误后不会发起关闭连接＆＃34; Expect：100-continue＆＃34;而不是我们收到的不确定行为。

似乎在这种情况下关闭连接是唯一符合RFC的解决方案，并将导致确定性行为。

这个结论是否正确？