Python socket先发送HEAD请求后同连接GET仅获取部分网页内容问题

• 响应接收不完整导致的流错位
  你在收到HEAD请求的响应时，只执行了单次s.recv(512)就开始解析头字段。由于HTTP响应头的排列顺序并非固定，很多服务器会把Content-Length字段放在响应头靠前的位置，你第一次收到的几百字节数据里已经包含了这个字段，代码就判定响应接收完成，直接开始发送GET请求。
  但此时剩下的HEAD响应尾端（包含连接信息、头结束标记\r\n\r\n）还在网络传输途中，会积压在内核的接收缓冲区里。等你后续调用s.recv(8192)获取GET响应时，这些残留的HEAD数据会和最先到达的GET响应数据混在一起，挤占正常的响应缓冲区位置，最终导致你打印出来的GET内容被截断在页面body的随机位置——因为你拿到的字节流本身就是错位拼接的，根本不是完整的GET响应。
• TCP流式协议的固有使用漏洞
  TCP是面向字节流的传输协议，单次s.recv()的返回值，只代表当前内核缓冲区里已经收到的全部字节，永远不能保证一次调用就取到完整的HTTP应用层报文。你的代码在发送GET请求后仅调用了一次recv就直接打印结果，没有按照解析到的Content-Length值循环接收、累加字节直到凑够完整的响应长度，本身逻辑就有缺陷。
  之前直接发GET能正常拿到完整页面，只是因为当时网络状态理想、服务器一次性把全量响应推到了客户端缓冲区，单次recv刚好取到了所有数据，属于偶然情况，不代表代码逻辑是正确的。
• 长连接状态不匹配
  你用HTTP/1.1发请求时没有显式声明连接模式，服务器默认会开启长连接复用TCP会话。但长连接的使用要求是，客户端必须严格读完上一个响应的所有字节，才能发送下一个请求；如果上一个响应有残留未读数据就发新请求，服务器的响应流会出现错位，表现出来就是GET请求只返回半段页面内容，剩余的缺失内容要等下一次请求触发时才会被服务器补推回来。

• 接收HEAD响应时，循环读数据直到识别到头结束标记\r\n\r\n，确认所有响应头完全接收完毕后，再发送GET请求。
• 接收GET响应时，根据Content-Length标记的总长度，循环调用recv累加接收字节，直到凑够完整长度再做解析，不能依赖单次recv的返回结果。
• 如果不需要长连接复用，可以在请求头里显式加上Connection: close，让服务器响应完成后主动关闭TCP连接，从根源上避免残留数据导致的流错位问题。

内容的提问来源于stack exchange，提问作者Caio Francisco