X-Pad:避免apache添加的浏览器bug头

Question

我看到这个标头附加到apache的响应中.它在新时代的浏览器中是否有任何意义; 或者仅仅是为了规避旧版Netscape中的错误.看起来很奇怪.

编辑

我正在对我们的应用程序进行性能测试,当我在Jmeter响应文本中看到时,有一个奇怪的标题返回.它说:

X-pad: avoid browser bug

而已!所以我尝试了一些谷歌搜索,似乎为Netscape浏览器的bug添加了一个标题.无论如何,我仍然很好奇,因为我们离这些版本的浏览器太远了(谢天谢地),有没有一个坚实的理由,它仍然存在.我们使用apache2.

希望这些细节有所帮助.

干杯

Answer 1

不,现在这是一个残余的头球; 也就是说,它被放在那里解决浏览器中的一个过时的错误(比IE6早几代 - 据报道修复了1997年,15年前的错误!)并且没有人再使用它了.

自2008年以来,删除它的补丁是在Apache的SVN中,但它显然仍然没有传播到所有发行版(加上一些站点可能使用Apache的非更新版本).

这是从源头获取的标题的注释:

/* Navigator versions 2.x, 3.x and 4.0 betas up to and including 4.0b2
 * have a header parsing bug.  If the terminating \r\n occur starting
 * at offset 256, 257 or 258 of output then it will not properly parse
 * the headers.  Curiously it doesn't exhibit this problem at 512, 513.
 * We are guessing that this is because their initial read of a new request
 * uses a 256 byte buffer, and subsequent reads use a larger buffer.
 * So the problem might exist at different offsets as well.
 *
 * This should also work on keepalive connections assuming they use the
 * same small buffer for the first read of each new request.
 *
 * At any rate, we check the bytes written so far and, if we are about to
 * tickle the bug, we instead insert a bogus padding header.  Since the bug
 * manifests as a broken image in Navigator, users blame the server.  :(
 * It is more expensive to check the User-Agent than it is to just add the
 * bytes, so we haven't used the BrowserMatch feature here.
 */