正如@DW 指出的那样，这将起作用——保护cookie。路径本身位于标头之前，如果它在可预测的位置包含敏感数据，也可能存在风险（这在当今并不常见，但用于会话管理的 URL 重写曾经很流行）。

一个变体看起来像这样：

GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>

通过随机选择X，Y但这样X+Y是固定的，流中 cookie 的位置将在请求之间发生变化，攻击者无法检测到（因为标头的总长度是恒定的）。虽然不如简单地删除请求的前 256 个字节那么令人满意，但这应该足以将基于偏见的攻击恢复到数十亿个请求中，而不是数百万个请求，而且只需不到 256 个额外字节即可完成每个请求的字节数（X+Y = 32应该这样做）。

这对于我所知道的所有攻击都是安全的。

从安全角度来看，它并不完全等同于删除前 256 或 512 个字节。根据您的提议，攻击者有一些已知的明文（例如，来自 GET 行和 X-Padding-Header），而如果您丢弃前 256 个字节，攻击者就不会在这些位置获得已知的明文。从理论上讲，如果知道 RC4 输出的前 256 个字节中的某些字节允许攻击者恢复密钥，那么您的方案将是不够的。但是，我不知道对这种形式的 RC4 的任何攻击。在实践中，所有已知的对 RC4 的攻击都表明 RC4 输出的第一个字节中的一个或两个略有偏差，因此它们不会像您想要的那样隐藏明文——但这种偏差不会允许攻击者推断出 RC4 密钥。所以从安全的角度来看，在实践中，

但是...从性能的角度来看，您刚刚为通过 SSL 发送的每个请求添加了 256 个字节。这对性能非常不利。这个性能问题可能足以扼杀这个提议；它可能不是一个可行的部署候选者。

如果浏览器想要修复它，最好简单地更新到 TLS 1.2 和更安全的密码套件。