Re: [PATCH] mod_proxy, yet another netscape bug

[Marc Slemko <ma...@worldgate.com>]

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.

Re: [PATCH] mod_proxy, yet another netscape bug

[Marc Slemko <ma...@worldgate.com>]

Not that I am aware of.  It would take someone who understands basic C
code to do that.

On Sun, 2 Aug 1998, Lars Eilebrecht wrote:

> According to Marc Slemko:
> 
> >  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?
> 
> No I'm not sure, but wasn't this bug fixed in the current Navigator versions?
> 
> 
> ciao...
> -- 
> Lars Eilebrecht                            - Hackers do it with bugs.
> sfx@unix-ag.org
> http://www.home.unix-ag.org/sfx/
> 

Re: [PATCH] mod_proxy, yet another netscape bug

[Lars Eilebrecht <La...@unix-ag.org>]

According to Marc Slemko:

>  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?

No I'm not sure, but wasn't this bug fixed in the current Navigator versions?


ciao...
-- 
Lars Eilebrecht                            - Hackers do it with bugs.
sfx@unix-ag.org
http://www.home.unix-ag.org/sfx/