Hi I have activated LiveHttpHeaders and the RequestDumperValve and fortunately ran into the problem in my development environment. Sorry for the long posting, but it seems necessary to me.
Important notes: - Between the client and the server, there is a reverse proxy. - After all, this is *one* sample of the case; this might not be representative. But because the problem occurs rarely, it's difficult to obtain data from another such case. The server was not under heavy load. I observed the following points: 1. catalina_log: the log order of the request dumper value sections seems to be out of order/interlaced with another request. - Expected:2007-01-22 10:07:04 RequestDumperValve[Catalina]: =============================================================== 2007-01-22 10:07:04 RequestDumperValve[Catalina]: REQUEST URI =/evalblappl/img/german/logo_bank.gif
[...] 2007-01-22 10:07:04 RequestDumperValve[Catalina]: isSecure=false2007-01-22 10:07:04 RequestDumperValve[Catalina]: --------------------------------------------------------------- 2007-01-22 10:07:04 RequestDumperValve[Catalina]: ---------------------------------------------------------------
2007-01-22 10:07:04 RequestDumperValve[Catalina]: authType=null 2007-01-22 10:07:04 RequestDumperValve[Catalina]: contentLength=1131 2007-01-22 10:07:04 RequestDumperValve[Catalina]: contentType=image/gif [...]2007-01-22 10:07:04 RequestDumperValve[Catalina]: ===============================================================
<next REQUEST URI> - Observed:2007-01-22 09:52:36 RequestDumperValve[Catalina]: =============================================================== 2007-01-22 09:52:36 RequestDumperValve[Catalina]: REQUEST URI =/evalblappl/img/invis.gif
[...] 2007-01-22 09:52:36 RequestDumperValve[Catalina]: isSecure=false2007-01-22 09:52:36 RequestDumperValve[Catalina]: --------------------------------------------------------------- 2007-01-22 09:52:36 RequestDumperValve[Catalina]: REQUEST URI =/evalblappl/img/german/logo_bank.gif
[...] 2007-01-22 09:52:36 RequestDumperValve[Catalina]: isSecure=false2007-01-22 09:52:36 RequestDumperValve[Catalina]: --------------------------------------------------------------- 2007-01-22 09:52:36 RequestDumperValve[Catalina]: ---------------------------------------------------------------
2007-01-22 09:52:36 RequestDumperValve[Catalina]: authType=null 2007-01-22 09:52:36 RequestDumperValve[Catalina]: contentLength=45 2007-01-22 09:52:36 RequestDumperValve[Catalina]: contentType=image/gif [...]2007-01-22 09:52:36 RequestDumperValve[Catalina]: =============================================================== 2007-01-22 09:52:36 RequestDumperValve[Catalina]: ---------------------------------------------------------------
2007-01-22 09:52:36 RequestDumperValve[Catalina]: authType=null 2007-01-22 09:52:36 RequestDumperValve[Catalina]: contentLength=-1 2007-01-22 09:52:36 RequestDumperValve[Catalina]: contentType=null [...]2007-01-22 09:52:36 RequestDumperValve[Catalina]: ===============================================================
<next REQUEST URI> 2. liveheaders: The GIF is returned with return code 200 but content length 0 (should be 1131). Plus: the content type is text/html insted of text/gif. - Expected: HTTP/1.x 200 OK Date: Mon, 22 Jan 2007 09:07:04 GMT Server: Apache Content-Length: 1131 Etag: W/"1131-1169216720000" Last-Modified: Fri, 19 Jan 2007 14:25:20 GMT Keep-Alive: timeout=2, max=498 Connection: Keep-Alive Content-Type: image/gif - Observed: HTTP/1.x 200 OK Date: Mon, 22 Jan 2007 08:52:36 GMT Server: Apache Content-Length: 0 Keep-Alive: timeout=2, max=498 Connection: Keep-Alive Content-Type: text/htmlThe observed values are not the same as in LiveHttpHeaders. This is probably because there
is a reverse proxy between the server and the client. 3. localhost_access: The return code is "200 -" (should be "200 1131"). (Note: IP & domain have been anonymized, parameters after '?' have been left out). - Expected:192.168.1.25 - - AFC9F2376CB7CE72614B7134DA6B7074 [22/Jan/2007:10:07:04 +0100] HTTP/1.1 GET /evalblappl/img/german/logo_bank.gif 200 1131 https://mybank.company.ch/finnojet-blappl/defAccountStatementOfAccount.account Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
- Observed:192.168.1.25 - - AFC9F2376CB7CE72614B7134DA6B7074 [22/Jan/2007:09:52:36 +0100] HTTP/1.1 GET /evalblappl/img/german/logo_bank.gif 200 - https://mybank.company.ch/finnojet-blappl/defAccountAssetOverview.account Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Does that help for further analysis? Andy Andreas Deller wrote:
Hi A typical entry looks like this: 192.168.11.11 - - [05/Jan/2007:11:23:59 +0100] "GET /ebanking/css/custom.css HTTP/1.1" 200 - "https://some.bank.ch/ebanking/login" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"The files are all correct, since they most of the time are delivered and displayed correctly. They can be requested independently.Curious. Can you replicate the problem, or is it intermittent?Unfortunately, it's very rare (at least in our development environment), which makes it difficult to track.You may find using the IE equivalent of Firefox's LiveHttpHeaders plugin useful in examining what the browser is sending and receiving.Good idea. I'll keep LiveHeaders on at all times.Also, try enabling the request dumper valve to get a closer look at what's happening on the server.http://tomcat.apache.org/tomcat-5.0-doc/config/valve.htmlThanks for the hint; I'll try this out!Regards Andy Pid wrote:Andreas Deller wrote:Hi I posted this unsuccessfully a week ago under 'Tomcat 4.1.30/5.0.28 empty responses - return code "200 -"', so I rephrase and shorten my question. OS: Solaris & Debian, Tomcat version 4.1.30 and 5.0.28. In the access logs, there are a number of entries with the HTTP status code "200 -". So the client never sees the contents of these files, resulting in incorrect layout (the problem just turns up with static files). I've tried the Tomcat doc, Google, FAQ, mailing lists to no avail. What am I doing wrong? Thanks Andy DellerCan't see your original message in the list i'm afraid.I don't understand your question either - you're saying that you see a 200 in the logs, the server returns a static file (do you mean an empty file?).Can you, perhaps, explain in more detail? p
smime.p7s
Description: S/MIME Cryptographic Signature