X-Pad: avoid browser bug header added by apache

Question

I see this header appended to the response from apache. Does it have any significance in new age browsers; or it's merely there to circumvent a bug in older versions of Netscape. Seems weird.

EDIT

I was doing a performance testing on our app, when I saw that in Jmeter response text, there was this weird header that comes back. It said:

X-pad: avoid browser bug

Thats it! So I tried some googling, and it seemed like a header added for Netscape browsers' bug. Anyway, I am still curious, that since we are so far away from those versions of browser (thankfully), is there a solid reason that it's still there. We use apache2.

Hopefully those details help.

Cheers

Answer 1

I know that the answer has been accepted but still I think this would be useful for users running php.
If you're a php user and you're getting this header. You can turn it off using custom "X-Powered-By" header.
For Example:
header('X-Powered-By: Powerful Management'); you can also remove it this way
header_remove('X-Pad');, sometimes setting that header to empty also removes it:
header('X-Pad:')
and bam your X-Pad header will disappear

Answer 2

Nope, it's a vestigial header nowadays; that is to say, it was put there to work around a bug in a browser which is obsolete (several generations older than IE6 - the bug was reported fixed as of 1997, 15 years ago!) and nobody uses it any more.

The patch to remove it is in Apache's SVN since 2008, but it apparently still hasn't propagated to all distributions (plus some sites may use non-updated versions of Apache).

Here's the comment for the header, picked up from the source:

/* 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.
 */