我有两台机器，A和B.
A向B发送HTTP请求并要求提供某些文档。 B回复并发送请求的文档并发出200 OK消息，但机器A抱怨由于网络故障而未收到文档。
HTTP代码200是否也可以作为收到文档的确认？
答案 0 :(得分：96)
HTTP 200代码是否也可以作为已收到文档的确认？
没有。完全没有。
甚至不能保证文件完全传输。
响应代码位于响应流的第一行。服务器可能会失败，或者在发送第一行和响应的最后一个字节之间的任何地方断开连接。服务器可能甚至不知道发生了这种情况。
实际上，服务器无法知道客户端是否收到完整（或部分）HTTP响应。 HTTP协议中没有提供确认的条款。
现在，您可以在HTTP顶部实现一个应用程序协议，其中客户端需要向服务器发送第二个HTTP请求，说“是的，我收到了文档”。但这将涉及在用户浏览器中实现的一些“应用程序逻辑”;例如在Javascript。
答案 1 :(得分：13)
绝对不是。 HTTP 200由服务器生成，并且仅意味着它理解该请求并认为它能够实现它（例如文件实际上在那里）。 传输完整响应文档（网络连接断开，数据包丢失等）时可能会出现各种错误，这些错误不会出现在HTTP响应中，但需要单独检测。
答案 2 :(得分：10)
这里有一个非常好的HTTP协议指南：http://blog.catchpoint.com/2010/09/17/anatomyhttp/
您应该区分HTTP协议和底层流传输协议，这对于HTTP目的应该是可靠的。流传输协议将确认所有数据传输，包括响应，以便交换的两端将确认数据被正确传输。如果传输流发生故障，那么您将遇到网络故障＆＃39;或类似的错误。发生这种情况时，HTTP协议无法继续;数据不再可靠甚至不完整。
在HTTP级别，200 OK消息的含义是服务器具有您之后即将传输给您的文档。通常，您也会获得一个内容长度的标题，这样您就可以确定是否/何时完成正文作为流协议之上的附加检查。从HTTP协议的角度来看，响应不会收到确认，因此一旦发送了响应，就没有验证。
但是，由于流传输是可靠的，因此发送响应的行为将成功或导致错误。这确实验证了文档是否已被网络目标接收（如TripeHound所述，在非直接连接的情况下，例如代理，这不是向最终目标传递的保证。）
答案 3 :(得分：6)
很容易看出200 OK响应代码无法保证响应文档的任何内容。它是在文件传输之前发送的，因此只有违反因果关系才能使其依赖于文档的成功接收。它仅用作指示正确接收请求并且服务器认为它能够满足请求。如果请求需要额外的处理（例如运行脚本），而不是仅仅返回一个静态文档，响应代码通常应该在完成后发送，因此通常表明这是成功的（但有些情况下这是是不可行的，例如具有持久连接和推送通知的请求 - 脚本可能会在以后失败。
在更一般的层面上，由于Two Generals Problem，永远不可能绝对保证所有消息都已在任何协议中被接收。没有确认系统可以解决这个问题，因为在某些时候必须有最后的确认;没有办法知道这是否成功收到，因为这需要另一个确认，与前一个确认相矛盾。
答案 4 :(得分：3)
HTTP的设计意识到各种“中间盒”的可能性 - 代理在有或没有客户知识的情况下运行。
如果涉及代理，那么即使知道服务器已经传输了所有数据并收到了正常的关闭连接，也不会告诉您生成HTTP请求的机器是否已收到文件的任何信息
答案 5 :(得分：-3)
A向B发送请求。在阻止请求到达B的方式中可能存在各种障碍。在https的情况下，请求可能到达B但被拒绝并且它被视为没有达到B.在所有这些情况下，B都不会发送任何状态。
一旦请求到达B，并且没有错误导致B崩溃，并且没有硬件故障等.B将检查请求并确定要执行的操作和要报告的状态。如果A请求存在的文件且允许A访问，则B将开始与文件数据一起发送“状态200”。
同样，各种各样的事情都可能出错。 A可能没有收到任何信息，或者没有数据或不完整数据等的“状态200”。（通过“接收”我的意思是数据到达以太网电缆，或通过WiFi）。
通常A的用户会使用一些处理丑陋位的库。使用一些像样的库，用户可能会遇到一些错误，或者状态已完成相应的数据。如果状态200只有一半的数据到达A，则用户将（根据库的设计）收到错误，而不是状态，并且绝对不是状态200.
或者你可能有一个报告状态200的库并告诉你“这里是前2,000个字节”，“这是接下来的2,000个字节”等等，在某些情况下出现问题时，你可能会被告知“抱歉，发生错误，数据不完整“。
但一般来说，用户获得状态200而没有数据的情况不会发生。