Safari浏览器在使用JavaScript Fetch API发送POST请求时，可能出现请求体（body）无法被后端服务器完整接收的问题，即便`Content-Length`头已正确设置。这通常是由于Safari分块发送请求体，而简易TCP服务器未持续读取套接字导致。本文将详细阐述此问题成因，并提供通过修改服务器端接收逻辑来确保完整获取请求体的解决方案。
理解问题：Safari与Fetch API的POST请求行为
在使用JavaScript的fetch API进行POST请求时，开发者可能会遇到一个令人困惑的现象：在Chrome或Firefox等浏览器中，请求能够正常发送并被后端服务器完整接收其请求体；然而，在Safari浏览器中，尽管前端控制台显示请求已发送且包含数据，但后端服务器（尤其是基于原生TCP套接字实现的简易服务器）却只接收到请求头，而请求体部分为空。Content-Length头部字段在请求中看似正确，但服务器端实际接收到的数据却不符合预期。
这种问题往往容易被误诊为CORS（跨域资源共享）配置错误、Content-Type设置不当或其他HTTP协议层面的问题。然而，经过排查发现，问题并非出在这些常见原因上，而是与Safari浏览器处理POST请求体的方式，以及服务器端对TCP流的读取方式有关。
深入剖析：TCP套接字服务器的接收机制
HTTP协议是基于TCP/IP协议的应用层协议。当客户端（浏览器）发送HTTP请求时，它实际上是通过TCP套接字将数据流发送到服务器。一个典型的HTTP POST请求结构包括：请求行、请求头、空行（\r\n\r\n）以及请求体。
对于一个简易的TCP套接字服务器，通常会使用socket.recv(buffer_size)方法来接收客户端发送的数据。如果服务器仅执行一次recv操作，并假设所有请求数据（包括请求体）都在这一个数据包中完整到达，那么当实际情况并非如此时，就会出现问题。
问题的核心在于：Safari浏览器在发送POST请求时，可能会将请求头和请求体分批次发送。这意味着，服务器的第一次recv操作可能只接收到请求头和部分（甚至没有）请求体，而请求体的其余部分会在后续的TCP数据包中陆续到达。如果服务器在接收到第一个数据包后就立即停止读取并处理，那么它将无法获取到完整的请求体数据。相比之下，curl工具或更高级的HTTP服务器框架能够自动处理这种分块接收的情况，确保读取到完整的请求。
解决方案：确保完整接收POST请求体
要解决Safari浏览器分块发送POST请求体的问题，服务器端必须调整其数据接收逻辑，确保持续从TCP套接字中读取数据，直到接收到的请求体长度与Content-Length头部字段所指定的值相匹配。
以下是一个Python简易TCP服务器的示例，展示了如何修改handle_request函数以正确接收完整的POST请求体：
import socket
def handle_request(raw_request_bytes, client_socket):
"""
处理客户端请求，确保完整接收POST请求体。
"""
request_str = raw_request_bytes.decode('utf-8')
# 尝试分割请求头和请求体
try:
headers_str, initial_body_str = request_str.split("\r\n\r\n", 1)
except ValueError:
# 如果初始接收的数据中没有完整的分隔符，可能需要更多数据
# 实际生产环境应更健壮地处理这种情况
print("Received incomplete request headers or no body separator.")
return "HTTP/1.1 400 Bad Request\r\n\r\nIncomplete request headers."
content_length = 0
# 从请求头中提取Content-Length
for line in headers_str.split("\r\n"):
if line.lower().startswith("content-length:"):
try:
content_length = int(line.split(": ")[1].strip())
except (ValueError, IndexError):
print("Invalid Content-Length header.")
return "HTTP/1.1 400 Bad Request\r\n\r\nInvalid Content-Length."
break
body_bytes = initial_body_str.encode('utf-8') # 将已接收的body部分转为字节
# 如果Content-Length大于已接收的body部分，则继续读取
while len(body_bytes) < content_length:
# 每次读取1024字节，直到body完整
chunk = client_socket.recv(1024)
if not chunk: # 客户端断开连接或没有更多数据
print("Client disconnected or incomplete body received.")
return "HTTP/1.1 400 Bad Request\r\n\r\nIncomplete body received."
body_bytes += chunk
# 此时，body_bytes 包含了完整的请求体
final_body_str = body_bytes.decode('utf-8')
# 重新组合完整的请求字符串（用于后续处理，例如解析URL、方法等）
full_request_str = headers_str + "\r\n\r\n" + final_body_str
print( "REQUEST TO HANDLE")
print( full_request_str)
if full_request_str.startswith("POST /checkdo-post HTTP/1.1"):
# 假设这里有一个 extract_token 和 is_authorized 函数
# token = extract_token(full_request_str)
# if is_authorized(token):
print( "DATA")
print( final_body_str) # 打印完整的请求体
# store_data(token, final_body_str) # 存储数据
response = "HTTP/1.1 200 OK\r\n\r\n"
response += "Data saved successfully!"
# else:
# response = "HTTP/1.1 403 Forbidden\r\n\r\n"
# response += "Unauthorized access!"
elif full_request_str.startswith("GET /checkdo.html HTTP/1.1"):
# 假设这里有 checkdo 变量
checkdo = "Hello GET!
"
response = "HTTP/1.1 200 OK\r\n"
response += "Content-Type: text/html\r\n"
response += "Content-Length: {}\r\n".format(len(checkdo))
response += "\r\n" + checkdo
else:
response = "HTTP/1.1 404 Not Found\r\n\r\n"
return response
def start_server():
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = ('', 8080)
server_socket.bind(server_address)
server_socket.listen(1)
print("Server listening on port 8080...")
while True:
client_socket, client_address = server_socket.accept()
print("Received connection from:", client_address)
# 初始接收数据，可能只包含部分请求头或请求体
initial_raw_request = client_socket.recv(4096)
print( "RECEIVE initial")
print( initial_raw_request)
# 调用修改后的处理函数
response = handle_request(initial_raw_request, client_socket)
print( "RESPOND")
print( response)
client_socket.sendall(response.encode('utf-8'))
client_socket.close()
if __name__ == "__main__":
start_server()代码解析：
- 分割请求头和初始请求体：首先，尝试使用split("\r\n\r\n", 1)将接收到的原始字节流解码为字符串，并分割成请求头和可能存在的初始请求体部分。
- 提取Content-Length：遍历请求头，找到并解析Content-Length字段，获取预期的请求体总长度。
-
循环接收剩余请求体：
- 将已接收的initial_body_str转换为字节流body_bytes。
- 进入一个while循环，只要body_bytes的长度小于content_length，就继续调用client_socket.recv(1024)从套接字中读取更多数据。
- 每次读取到的数据块都会追加到body_bytes中，直到body_bytes的长度达到或超过content_length。
- 解码最终请求体：当body_bytes包含完整请求体后，将其解码为UTF-8字符串，即可进行后续处理。
注意事项：
- 解码时机：在将原始字节流分割成请求头和请求体之前，通常需要先进行一次解码（例如decode('utf-8')），以便进行字符串操作（如split、startswith等）。然而，如果请求体可能包含非文本（二进制）数据，则应先完成字节流级别的分割和聚合，再根据Content-Type决定如何解码或处理。在上述示例中，假设请求体是UTF-8文本，所以先解码了。
- 错误处理：生产环境中的服务器需要更健壮的错误处理机制，例如处理Content-Length缺失或格式错误、客户端提前断开连接等情况。
- 缓冲区大小：recv(1024)中的1024是每次读取的缓冲区大小，可以根据实际情况调整。
- 生产环境框架：对于实际的Web应用开发，强烈建议使用成熟的Web框架（如Python的Flask、Django，Node.js的Express等）。这些框架内置了对HTTP协议的完整解析和数据流处理能力，包括自动处理分块传输、Content-Length校验等，无需开发者手动实现底层TCP套接字逻辑。
总结
Safari浏览器在通过Fetch API发送POST请求时，其请求体可能以分块的形式发送。对于基于原始TCP套接字实现的简易服务器，这要求服务器必须主动且持续地从套接字中读取数据，直到接收到的请求体长度与HTTP请求头中的Content-Length字段完全匹配。通过实现一个循环读取机制，可以确保服务器能够完整地接收所有浏览器（包括Safari）发送的POST请求体，从而避免数据丢失问题。在实际开发中，利用成熟的Web框架是更高效和可靠的选择，因为它们已经封装了这些复杂的底层细节。
