httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: [PATCH] mod_proxy, yet another netscape bug
Date Sun, 02 Aug 1998 00:46:08 GMT
On Sun, 2 Aug 1998, Lars Eilebrecht wrote:

> Hi,
> a friend of mine discovered a Navigator/Mozilla bug which
> results in broken images in some rare cases.
> (I was able to reproduce the bug under Solaris 2.6 with Netscape
>  Communicator 4.05.)
> If you load a page that contains _direct_ links to images via mod_proxy
> and try to load the images you'll maybe receive a broken image (is does
> not happen with inline images).
> Dependent on the length of the http header and TCP/IP settings/values
> (MTU, path-MTU, segment size etc) the first read() of Netscape reads
> the header plus the beginning of the body. But it seems that Netscape
> expects to see only http headers in his first read(), because
> the beginning of the body gets ignored. Therefore Netscape fails to
> display the image. Shift-Reloading the image-URL works...

Are you sure this isn't just the same thing as the 25[678] byte Navigator
bug that we already work around, but perhaps showing up differently
because it is coming from the proxy?

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

> The patch contains a workaround for this bug (added a call to
> ap_bflush() in proxy_http.c/proxy_ftp.c right before mod_proxy

I don't like that fix.  It is the wrong way to do things.

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message