You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by Nathan Lutchansky <lu...@litech.org> on 2001/04/21 20:15:16 UTC
Keepalive issues
Hello everyone,
I'm in the process of upgrading my webserver to Apache 2.0, but since I
need mod_php and mod_perl, I'm leaving Apache 1.3.12 running on a
different port to service some parts of the site. Thus my need for
mod_proxy.
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.
Anyway, now that it's all up and running, I'm pretty happy with it. I'm
using it with both ProxyPass and the RewriteRule [P] flag and it all seems
to work fine.
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.
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.
I hope this is enough information to track down the problem. -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> 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.
I think I've nailed it (I managed to reproduce it with Netscape v4.7,
and the fix has caused the problem to go away).
The proxy was trying to read an entity from the backend server when no
entity was expected. The proxy waited on the read, the backend waited
for the next request, until it timed out.
You'll need to update the entire http-2.0 tree in addition to the
http-proxy tree to get this fix, as a change has been made to the filter
code that affects the proxy.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by "Victor J. Orlikowski" <v....@gte.net>.
No. Not fixed. Yet. Finishing this today/tomorrow.
Been sick. :)
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
"Victor J. Orlikowski" wrote:
> Fine by me, as I haven't touched that all evening.
> But I should have a fix by about noon tomorrow, if you don't beat me
> to it.
> I hate being out of commission for a week. :p
Managed to get a fix in just now... :)
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by "Victor J. Orlikowski" <v....@gte.net>.
Fine by me, as I haven't touched that all evening.
But I should have a fix by about noon tomorrow, if you don't beat me
to it.
I hate being out of commission for a week. :p
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
"Victor J. Orlikowski" wrote:
> Temporarily derailed ... currently attacking DSO building problems ...
> Must ... avoid ... desire to ... context switch.
> I really need to go SMP one of these days - Zaphod really has a good
> thing going for him.
I think I figured it out - busy playing with ideas now.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by "Victor J. Orlikowski" <v....@gte.net>.
<snip>
> Err... Since HTTP/1.1 specifies that keepalive is enabled by default, the
> proxy should *always* expect it to be on. Unless, of course, it sends a
> "Connection: close" header in the request.
>
> I'm assuming that Victor knows what this problem is since he said he was
> working on it. :-)
</snip>
Temporarily derailed ... currently attacking DSO building problems ...
Must ... avoid ... desire to ... context switch.
I really need to go SMP one of these days - Zaphod really has a good
thing going for him.
:)
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
orlikowski@apache.org
vjo@us.ibm.com
Re: Data corruption (was: Re: Keepalive issues)
Posted by Nathan Lutchansky <lu...@litech.org>.
On Wed, 2 May 2001, Graham Leggett wrote:
> > I would guess that this type of data corruption happens with post requests
> > too, but I haven't tried it.
>
> Can you pull the httpd-2.0 and http-proxy trees and try again? I rebuilt
> the tree this afternoon and the problem that was breaking Akamai
> accesses was fixed. The Akamai problem was a memory corruption problem,
I rebuilt my apache from CVS as soon as I got this email, but I just now
got a chance to test things out. The memory corruption problem is gone,
so I think now Apache and mod_proxy in general work perfectly for me.
-Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Data corruption (was: Re: Keepalive issues)
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> I would guess that this type of data corruption happens with post requests
> too, but I haven't tried it.
Can you pull the httpd-2.0 and http-proxy trees and try again? I rebuilt
the tree this afternoon and the problem that was breaking Akamai
accesses was fixed. The Akamai problem was a memory corruption problem,
I would strongly suspect that you are experiencing the same problem,
different symptom.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Data corruption (was: Re: Keepalive issues)
Posted by Nathan Lutchansky <lu...@litech.org>.
On Sat, 28 Apr 2001, Graham Leggett wrote:
> Nathan Lutchansky wrote:
>
> > Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
> > my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
>
> Doing this is dangerous - because then there is no point in fixing
> problems with HTTP/1.1 and the proxy. The HTTP/1.1 protocol is
> backwardly compatible with HTTP/1.0 - if it doesn't work, it's because
> something is broken and should be fixed.
Yeah, you're right. I guess I shouldn't be lazy about debugging this.
> Essentially before reverting to HTTP/1.0, first try switching Keepalives
> off on the proxy server and see if that makes a difference. The proxy
> will only use a backend-proxy Keepalive if a browser-proxy Keepalive is
> currently active. This will at least reduce the range of the problems,
> and make things easier to track down.
Same problem happens regardless of whether keepalive is used, but that's
not surprising, considering what the bug is.
I pulled out tcpflow just to see where things were hanging, and it's
pretty clear that there's a bug here. When Netscape uses a PUT request to
store the liprefs file, the data it sends gets corrupted on the way
through the proxy. I've attached an example capture for both the data
from the browser and the data from the proxy. Parts of the client data
are being zeroed on the way through the proxy, and the data is being
truncated. This explains why the symptom was Netscape hanging - the
Content-length header has the correct length, but the proxy loses some
data as well as corrupting it.
This definitely wasn't happening with the last build, so something changed
in the last week that broke the proxy.
I would guess that this type of data corruption happens with post requests
too, but I haven't tried it.
I've tried this test with several hosts. Interestingly, the farther the
host is from the server, the fewer problems it has. With a host on a
local DSL line, the data still gets truncated, but there's no corruption.
With a host on the other side of the continent, the data doesn't even get
truncated. I have a feeling this is a synchronization issue, but I can't
put my finger on it.
Any ideas? -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
> my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
Doing this is dangerous - because then there is no point in fixing
problems with HTTP/1.1 and the proxy. The HTTP/1.1 protocol is
backwardly compatible with HTTP/1.0 - if it doesn't work, it's because
something is broken and should be fixed.
Essentially before reverting to HTTP/1.0, first try switching Keepalives
off on the proxy server and see if that makes a difference. The proxy
will only use a backend-proxy Keepalive if a browser-proxy Keepalive is
currently active. This will at least reduce the range of the problems,
and make things easier to track down.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
On Sat, 28 Apr 2001, Graham Leggett wrote:
> Nathan Lutchansky wrote:
>
> > > Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
> > > my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
> >
> > OTOH, if some kind soul who is more familiar with the Apache 2.0 API than
> > I am would like to port this 500-line module for me, I would be more than
> > grateful. :-) -Nathan
>
> Where does one get hold of mod_roaming? If I have a bit of time (and I
> nail that &%#^&$! Akamai bug) I'll take a look...
mod_roaming is available at:
http://www.klomp.org/mod_roaming/
Is PHP available for Apache 2.0? If I can get mod_roaming and mod_php
built into my 2.0 server, I can dispose of the backend 1.3 server
entirely. But I'll still need mod_proxy to service certain requests to
servers inside our internal network, so I'll still be testing things out
for this group... -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> > Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
> > my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
>
> OTOH, if some kind soul who is more familiar with the Apache 2.0 API than
> I am would like to port this 500-line module for me, I would be more than
> grateful. :-) -Nathan
Where does one get hold of mod_roaming? If I have a bit of time (and I
nail that &%#^&$! Akamai bug) I'll take a look...
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
On Sat, 28 Apr 2001, Nathan Lutchansky wrote:
> Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
> my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
OTOH, if some kind soul who is more familiar with the Apache 2.0 API than
I am would like to port this 500-line module for me, I would be more than
grateful. :-) -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
On Wed, 25 Apr 2001, Nathan Lutchansky wrote:
> > The latest CVS has this fixed - can you check this for me to see if it
> > works for you?
>
> Sure, I should be able to do it this afternoon. It's taken me a little
> longer because I had to pull the whole httpd-2.0 tree.
I finally got around to getting the current cvs versions of httpd-2.0 and
mod_proxy running. Both of the problems I was having earlier seem to be
solved.
I did find one other problem, but it is not directly the fault of
mod_proxy. I'm running the mod_roaming server on our backend 1.3 server
so that our Netscape users can store their roaming profiles on this
server. mod_proxy was able to proxy the roaming requests just fine when
wired for HTTP/1.0 only, but now that it's running HTTP/1.1 the roaming
requests are causing Netscape to hang. I have a feeling that mod_roaming
is simply not expecting to be receiving HTTP/1.1 requests and can't deal
with the 1.1 keepalive or something.
Thus, until I get around to porting mod_roaming to Apache 2.0, I resubmit
my request for an HTTP/1.0-option for mod_proxy. :-) -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
On Wed, 25 Apr 2001, Graham Leggett wrote:
> The latest CVS has this fixed - can you check this for me to see if it
> works for you?
Sure, I should be able to do it this afternoon. It's taken me a little
longer because I had to pull the whole httpd-2.0 tree.
For the record, I'm only using prefork. Last time I tried threaded Apache
was WAY too unstable... -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> Err... Since HTTP/1.1 specifies that keepalive is enabled by default, the
> proxy should *always* expect it to be on. Unless, of course, it sends a
> "Connection: close" header in the request.
Exactly - but when there are bugs it doesn't do that :)
> If I had to make a guess, I'd say that the proxy is waiting for the server
> to send the data associated with the reply, but according to HTTP/1.1
> spec, the 304 code is "special" and explicitly has no data. This should
> probably be a special case in the proxy code then... -Nathan
This was exactly the problem - the original proxy code didn't
distinguish between responses that returned entities and responses that
didn't because all responses ended with EOF.
The latest CVS has this fixed - can you check this for me to see if it
works for you?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
On Mon, 23 Apr 2001, Graham Leggett wrote:
> Nathan Lutchansky wrote:
>
> > 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.
Err... Since HTTP/1.1 specifies that keepalive is enabled by default, the
proxy should *always* expect it to be on. Unless, of course, it sends a
"Connection: close" header in the request.
I'm assuming that Victor knows what this problem is since he said he was
working on it. :-)
> > 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.
If I had to make a guess, I'd say that the proxy is waiting for the server
to send the data associated with the reply, but according to HTTP/1.1
spec, the 304 code is "special" and explicitly has no data. This should
probably be a special case in the proxy code then... -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
> Would it be possible to sniff the inbound and outbound connections on
> the mod_proxy machine using tcpflow to see who is saying what to what?
> I'd like to check the headers that are being sent and received, I have a
> hunch that the content-length header is not being sent correctly.
OK, after much testing, this is what I have discovered:
Chunked responses work just fine.
Backend server replies consisting of only headers are not returned to the
browser by the proxy until the connection to the backend times out and is
closed.
Explicitly disabling keepalive on the backend (with "Setenv nokeepalive")
causes mod_proxy to return only the headers, and not the payload, to the
client for non-200 requests.
Here's an example session... Apache 2.0.16 with mod_proxy from 4/19 is
serving on 128.84.154.54:8080 and proxying requests to Apache 1.3.12
serving on 127.0.0.1:899.
----------------------------------
Session between mod_proxy and 1.3:
----------------------------------
GET /%7Ecarson/foo HTTP/1.1
Host: localhost:899
Accept: */*
Accept-Encoding: gzip,deflate,compress,identity
Accept-Language: en
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; 0.8.1) Gecko/20010326
Max-Forwards: 10
X-Forwarded-For: 128.84.223.104
X-Forwarded-Host: marduk.litech.org:8080
X-Forwarded-Server: www.litech.org
HTTP/1.1 404 Not Found
Date: Mon, 23 Apr 2001 21:44:13 GMT
Server: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.5a mod_perl/1.24_01
PHP/4
.0.3pl1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
110
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /~carson/foo was not found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.12 Server at localhost Port 899</ADDRESS>
</BODY></HTML>
0
---------------END----------------
However, the client doesn't get the nice error message. Here's what the
client sees:
--------------------------------
Session between Mozilla and 2.0:
--------------------------------
GET /~carson/foo HTTP/1.1
Host: marduk.litech.org:8080
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; 0.8.1) Gecko/20010326
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 404 Not Found
Date: Mon, 23 Apr 2001 21:44:13 GMT
Server: Apache/2.0.16 (Unix)
Content-Type: text/html; charset=iso-8859-1
Content-Length: 0
-----------------END---------------------
I'm not sure what's going on here. This is what I get when I turn on
debugging:
[Mon Apr 23 18:08:59 2001] [notice] Apache/2.0.16 (Unix) configured --
resuming normal operations
[Mon Apr 23 18:08:59 2001] [info] Server built: Apr 23 2001 16:43:55
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(98): proxy: HTTP:
canonicalising URL //localhost:899/~carson/foo
[Mon Apr 23 18:09:09 2001] [debug] mod_proxy.c(386): Trying to run
scheme_handler
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(235): proxy: HTTP: serving
URL http://localhost:899/%7Ecarson/foo
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(263): proxy: HTTP
connecting http://localhost:899/%7Ecarson/foo to localhost:899
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(380): proxy: socket has
been created
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(427): proxy: socket is
connected
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(444): proxy: connection
complete
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(773): proxy: start body
send
[Mon Apr 23 18:09:09 2001] [debug] proxy_http.c(787): proxy: end body send
Sorry for the poor formatting.
Anyway, I hope this helps. Let me know if you need anything more.
-Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> It seems that mod_proxy does not support chunked responses. Is this
> correct, or do I have something configured wrong?
It should do - if there is a Transfer-Encoding header, and it contains
"chunk" as one of the options, the DECHUNK filter is added to the input
filters.
I tested it with the responses from Apache v1.3.12 and it worked -
though that's not to say that it necessarily works properly.
Would it be possible to sniff the inbound and outbound connections on
the mod_proxy machine using tcpflow to see who is saying what to what?
I'd like to check the headers that are being sent and received, I have a
hunch that the content-length header is not being sent correctly.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Graham Leggett <mi...@sharp.fm>.
Nathan Lutchansky wrote:
> It seems that mod_proxy does not support chunked responses. Is this
> correct, or do I have something configured wrong?
Also check if this is fixed - I noticed a variable was not being
initialised when passing data to the DECHUNK filter.
When I tested it now it worked for me. The chunked response was
dechunked, then chunked again by the rest of the proxy Apache. I've
attached the trace.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Keepalive issues
Posted by Chuck Murcko <ch...@topsail.org>.
Both chunking and persistent connections need some work. I thought I was
crazy, since no one seems to have seen the persistent connection problem
save me until now.
Thanks. The idea of a runtime downgrade option to 1.0 might be useful in
the long run, not just the beta timeframe.
Chuck
On Saturday, April 21, 2001, at 07:48 PM, Nathan Lutchansky wrote:
> Hi again,
>
> It seems that mod_proxy does not support chunked responses. Is this
> correct, or do I have something configured wrong?
>
> Many of the generated responses from Apache 1.3, particularly those for
> error and redirect messages, are sent in chunked format. Thus, any 404
> messages sent from my backend server do not get displayed by the client
> browser, and instead the user gets a blank page.
>
> I changed proxy_http.c to send HTTP/1.0 requests instead, and now it
> seems
> to work fine.
>
> Perhaps we could have a run-time configuration directive to force
> mod_proxy to use HTTP/1.0? At least until chunked replies are
> implemented, anyway. I'm sure this problem will be noticed as soon as
> mod_proxy makes it into the Apache 2.0 distribution if it is not at
> least
> documented.
>
> Thanks. -Nathan
>
> On Sat, 21 Apr 2001, Nathan Lutchansky wrote:
>
>> Hello everyone,
>>
>> I'm in the process of upgrading my webserver to Apache 2.0, but since I
>> need mod_php and mod_perl, I'm leaving Apache 1.3.12 running on a
>> different port to service some parts of the site. Thus my need for
>> mod_proxy.
>>
>> 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.
>>
>> Anyway, now that it's all up and running, I'm pretty happy with it.
>> I'm
>> using it with both ProxyPass and the RewriteRule [P] flag and it all
>> seems
>> to work fine.
>>
>> 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.
>>
>> 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.
>>
>> I hope this is enough information to track down the problem. -Nathan
>>
>>
>
> --
> +-------------------+---------------------+------------------------+
> | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
> +------------------------------------------------------------------+
> | I dread success. To have succeeded is to have finished one's |
> | business on earth... I like a state of continual becoming, |
> | with a goal in front and not behind. - George Bernard Shaw |
> +------------------------------------------------------------------+
>
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
Re: Keepalive issues
Posted by Chuck Murcko <ch...@topsail.org>.
Um, what version of httpd are you talking about, BTW? 8^)
On Sunday, April 22, 2001, at 01:05 AM, Chuck Murcko wrote:
> Both chunking and persistent connections need some work. I thought I
> was crazy, since no one seems to have seen the persistent connection
> problem save me until now.
>
> Thanks. The idea of a runtime downgrade option to 1.0 might be useful
> in the long run, not just the beta timeframe.
>
> Chuck
>
> On Saturday, April 21, 2001, at 07:48 PM, Nathan Lutchansky wrote:
>
>> Hi again,
>>
>> It seems that mod_proxy does not support chunked responses. Is this
>> correct, or do I have something configured wrong?
>>
>> Many of the generated responses from Apache 1.3, particularly those for
>> error and redirect messages, are sent in chunked format. Thus, any 404
>> messages sent from my backend server do not get displayed by the client
>> browser, and instead the user gets a blank page.
>>
>> I changed proxy_http.c to send HTTP/1.0 requests instead, and now it
>> seems
>> to work fine.
>>
>> Perhaps we could have a run-time configuration directive to force
>> mod_proxy to use HTTP/1.0? At least until chunked replies are
>> implemented, anyway. I'm sure this problem will be noticed as soon as
>> mod_proxy makes it into the Apache 2.0 distribution if it is not at
>> least
>> documented.
>>
>> Thanks. -Nathan
>>
>> On Sat, 21 Apr 2001, Nathan Lutchansky wrote:
>>
>>> Hello everyone,
>>>
>>> I'm in the process of upgrading my webserver to Apache 2.0, but
>>> since I
>>> need mod_php and mod_perl, I'm leaving Apache 1.3.12 running on a
>>> different port to service some parts of the site. Thus my need for
>>> mod_proxy.
>>>
>>> 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.
>>>
>>> Anyway, now that it's all up and running, I'm pretty happy with it.
>>> I'm
>>> using it with both ProxyPass and the RewriteRule [P] flag and it all
>>> seems
>>> to work fine.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> I hope this is enough information to track down the problem. -Nathan
>>>
>>>
>>
>> --
>> +-------------------+---------------------+------------------------+
>> | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
>> +------------------------------------------------------------------+
>> | I dread success. To have succeeded is to have finished one's |
>> | business on earth... I like a state of continual becoming, |
>> | with a goal in front and not behind. - George Bernard Shaw |
>> +------------------------------------------------------------------+
>>
>>
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
>
Re: Keepalive issues
Posted by Nathan Lutchansky <lu...@litech.org>.
Hi again,
It seems that mod_proxy does not support chunked responses. Is this
correct, or do I have something configured wrong?
Many of the generated responses from Apache 1.3, particularly those for
error and redirect messages, are sent in chunked format. Thus, any 404
messages sent from my backend server do not get displayed by the client
browser, and instead the user gets a blank page.
I changed proxy_http.c to send HTTP/1.0 requests instead, and now it seems
to work fine.
Perhaps we could have a run-time configuration directive to force
mod_proxy to use HTTP/1.0? At least until chunked replies are
implemented, anyway. I'm sure this problem will be noticed as soon as
mod_proxy makes it into the Apache 2.0 distribution if it is not at least
documented.
Thanks. -Nathan
On Sat, 21 Apr 2001, Nathan Lutchansky wrote:
> Hello everyone,
>
> I'm in the process of upgrading my webserver to Apache 2.0, but since I
> need mod_php and mod_perl, I'm leaving Apache 1.3.12 running on a
> different port to service some parts of the site. Thus my need for
> mod_proxy.
>
> 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.
>
> Anyway, now that it's all up and running, I'm pretty happy with it. I'm
> using it with both ProxyPass and the RewriteRule [P] flag and it all seems
> to work fine.
>
> 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.
>
> 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.
>
> I hope this is enough information to track down the problem. -Nathan
>
>
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | lutchann@litech.org | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+