>> Is length 1090 correct?`So does the full body have that length? Yes firefox reports that the page is 1k in size, via the web developer's tool bar. I have seen it happen in IE 6 and 7 also.
Would it be possible for me to email you directly the output of wireshark for both one bad and one good attempt? I really appreciate you helping me out on this one. Regards Ben Short On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > 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. > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
