PHP 应用程序使用 curl 发布 XML 数据；没什么特别的，输出看起来像（c/p，但标识符和密码已更改）：
Host: foreign.host.example
Authorization: Basic dGVzdDpnZWhlaW0=
User-Agent: ourhost HTTP-connector/1.0
Accept: */*
Referer: https://our.host.example/
Content-Type: text/xml
Content-Length: 9218
Expect: 100-continue
[9218 bytes of XML data]
这是在几个源主机 S1...Sn 上完成的，并发布到几个目标主机 T1...Tn。一周前，主机 S1 从 Debian/buster 升级到 Debian/bullseye；生成 PHP 软件也进行了升级，但我不知道这方面有任何变化（生成的请求看起来相同）。正是自这次升级以来，两个（不相关的）目标主机 T1 和 T2 拒绝了我们的请求，响应代码为 400。如果从其他源主机（具有旧修订级别）连接，所有其他目标主机都可以正常工作，并且 T1/T2 也可以正常工作。
推论：错误在我们这边。但是哪里？
附注：删除 Expect 标头不会改变任何内容。
补充信息：虽然 T1 仅使用响应代码 400 进行响应，但 T2 却很有礼貌，并包含如下状态消息：
[our.ip.address]:60760 has incomplete request: Estimated length was 3994 byte(s), received 3899 byte(s)
不幸的是，这个提示不足以启发我（那里的联系人也没有足够的知识来做到这一点），但它引导我得出以下结论
解决方法：如果我抑制 Content-Length 标头，传输就可以进行
这总比没有好，但并不令人满意——我希望问题得到解决；所以我反复检查了 Content-Length 标头中的数字（因为这是我目前能想到的唯一可能的错误来源）；看起来没问题，在仍在运行的主机 S2...Sn 上使用的计算方法完全相同。并且：内容长度加上估计的标头（这当然会因其他主机、授权和引用者而略有不同）既不是估计长度也不是接收长度，而是介于两者之间。到目前为止，响应提供了以下数字：
| 估计的 | 已收到 | 不同之处 |
|---|---|---|
| 4322 | 4228 | 94 |
| 3972 | 3877 | 95 |
| 3994 | 3899 | 95 |
| 6928 | 6768 | 160 |
不幸的是，这既不是恒定的，也没有任何意义。
我设置了几个标签，因为 Apache (2.4.52)、OpenSSL (1.1.1k)、curl (7.74.0) 和 PHP (7.4.25) 已随服务器一起升级，尽管我看不出有任何可能的影响。但我没有其他想法，所以我不想排除这种可能性。
欢迎任何想法。