Nathan Lutchansky wrote:

> I installed mod_proxy from CVS on Thursday, so I believe it's still up to
> date.  It went into Apache 2.0.16 as static, after several hours of
> fighting trying to get the .so to build correctly.  Argh.  This is a known
> problem, though.

Sorry about that - the build code as lifted from mod_dav, which doesn't
mention any of the shared options at all - static worked, but shared did
not. I saw a fix for this posted to CVS earlier.

> The one problem I'm having is that keepalive doesn't seem to work
> correctly.  The symptom is that loading documents that are already cached
> take 15-20 seconds *each* to load, when all that is being returned is a
> 304 status code.  This is a pain when loading a page with a large number
> of graphics as it can take several minutes to complete.  This problem
> occurs with both Mozilla 0.8.1 and MSIE 5.x.
> 
> When the following conditions are true, there is a 15-20 second delay in
> getting back a response:
> 
> 1) The browser supports keepalive.
> 2) The browser has the current page in the cache.
> 3) Current mod_proxy 2.0 is talking to an HTTP/1.1 backend server.
> 4) The backend returns a 304 status code for the request.

Hmmm - I originally encountered this when I was working on the keepalive
stuff. It happens when the backend server switches on keepalives, when
the proxy doesn't expect it to. The proxy then expects the backend
server to send data until it the connection is closed, but the backend
server keeps the connection alive - which eventually times out and
closes, causing the delay you are experiencing.

Could you send me a tcpflow trace of the conversation that goes on
between the browser and the proxy, and the proxy and the backend server
- the headers should give an indication of why this is happening.

> The workaround is to put a "SetEnv nokeepalive" on the backend server to
> disable keepalive on proxied requests.  I've also tried putting "SetEnv
> force-response-1.0" and "SetEnv downgrade-1.0" but they did not solve the
> problem.
> 
> Interestingly, when the browser does not have the page in its cache,
> keepalive seems to work fine when passing the full page back to the
> client.

The plot thickens...

When the page is in the cache, the browser will send an If-None-Match
conditional header. If the object is fresh, the backend will send back a
304 Not Modified. I have a feeling that the proxy is assuming that
responses without bodies (such as 304) are always non-keepalive - which
is bogus... will need to investigate this some more.

Regards,
Graham
-- 
-----------------------------------------
[EMAIL PROTECTED]               "There's a moon
                                        over Bourbon Street
                                                tonight..."

Reply via email to