ben short wrote:
Ok I have used wireshark and see that the request is sent to the
apache httpd. The next first packet i get back contains the
following...
HTTP/1.1 200 OK
Date: Tue, 31 Jul 2007 14:57:25 GMT
Server: Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7a mod_jk/1.2.23
Content-Length: 1090 ***NOTE every line but this has a \r\n shown
in the middle frame of wireshark ***
All Headers are supposed to end with \r\n, but I would find it very
strange, if this does not do it (I can not really think of a reson for
that, but who knows...)
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Language: en-GB
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=UTF-8
Is length 1090 correct?`So does the full body have that length?
<!--Rail Timestamp:
-->
<!--Generated by Journeycheck
4.0-RC5
on host
jc-pres2.nexusalpha.com
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html lang="english">
.<head>
..<meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
..<meta http-equiv="expires" content="0"/>
..<meta http-equiv="cache-control" content="no-cache"/>
..<meta http-equiv="pragma" content="nocache"/>
..<meta http-equiv="Content-Language" content="en-us"/>
..<meta content="Nexus Alpha:Andrew Langmead, Ben Short, Lawrence
Chan" name="author"/>
..<meta content="journey check,rail,journey,nexus
alpha,plan,disruption,transport,trains" name="keywords"/>
..<meta content="Allows you to check your journey with a particular
rail company" name="description"/>
..<!--<META HTTP-EQUIV="Refresh"CONTENT="10;
URL=http://www.jcheck.com/firstcapitalconnect/";>-->
..
..<link href="/resources/common/web/css/common.css" rel="stylesheet"
type="text/css"/>
..<!--<script type="text/javascript" src="/resources/common/web/javascript
Which is whats being shown in the browser, if i view the source.
Next I see more packets that say 'Continuation or non-HTTP traffic'
in the Info column of wireshark. When I look at the byte output I can
see that its the rest of the page.
If i use wireshark to view the same request with the webapp started I
dont see the initial HTTP/1.1 200 OK packet, so i assume that each
packet contains the correct headers for chunking to work correctly.
But the first line is mandatory for HTTP responses! So in the good case,
something is slipping the observation. We could ignore that, but if we
don't see something in the good case, we must question the observation
in the bad case too.
So it seams that im getting a dodgy content length in the first packet
if the request goes to the stoppped webapp first. Or infact the whole
chunking thing is not working correctly.
If there is a Cntent-Length header, there is no chunking involved.
Chunking gives a way of telling the length of small chunks of the
answer. For dynamic content it's often difficult to tell the full length
in advance, but a Content-Length header has to come before the body. So
chunking is used to prevent the need of buffering the full body before
sending it out. The reposnse you showed us above does not use chunking,
but instead the content-length header, which is OK and stable for
content with easy to determine length.
Which browser is it? If you can reproduce the problem with firefox,
there are very good plugins, that can show you details of communication
and content from inside the browser. A good example is FireBug, which I
can recommend. Even if you usually use MSIE, it might be important to
cross check with Firefox in order to find out if the problem is browser
specific.
Regards,
Rainer
On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote:
You could dig deeper into two different directions:
- protocol: is the content-length in the response headers correct? Or
does it use chunked transfer, and is this OK?
- sniff the network in front of the apache: do the packets actually get
send back to the browser?
Regards,
Rainer
ben short wrote:
I'm not getting anywhere with this :(
I have set the logging to trace for mod_jk and I can see all the
response packets. I have also turned on our applications response
logging and can see that the running webapp writes the full page to
the response. I can then see it all in the mod_jk logs. But the
browser only shows a partial page.
