I requested this URL a few seconds ago, using
curl -D - http://www.kpn.com/kpn/show/
and it had the header
Transfer-Encoding: chunked
set. This somehow contradicts your first mail.
Regards,
Rainer
Henk Fictorie wrote:
In the original posting I mentioned a monitoring tool which was triggered by
this behaviour. This monitoring tool has several machines watching our
website. I have been snooping the port 80 requests from these machines for
the last two days, but they haven't triggered the 300 sec. delay. I will try
again tomorrow...
The logfiles shows numerous request which are taking 300 sec., but they
aren't coming from our monitoring tool.
The failure rate is quite low. On one of our port 80 webservers it was
triggered yesterday 157 times on a total of 636270 requested tomcat pages.
So there isn't a particular page which always shows this behaviour, but some
pages do exhibit this behaviour more often than others. The best bet seems
to be the page http://www.kpn.com/kpn/show/
I should also mention that we use mod_deflate for compression. The
monitoring tool however doesn't accept compressed responses. So responses
are sent uncompressed, but it still passes the mod_deflate filter.
regards Henk Fictorie
Rainer Jung-3 wrote:
Hi Henk, do you have a simple app to reproduce the problem?
Rainer Jung schrieb:
Hi Henk,
I'll try to find the reason. Would it be easy for you to repeat the test
with a very raw client? If the URL is easy you could e.g. telnet to the
APACHE port and simply write
GET /myurlRETURN
RETURN
I'm asking for that, because the client write error sounds a little
strange to me, and I want to make sure, that it's not the client, which
produces the problem concerning the missing header.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
