-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
On 6/30/2010 3:32 PM, David Brown wrote:
> Problem:
>
> Extra characters showing up in some content delivered from tomcat. I believe
> they are from the JK connector when it breaks up the content into 8k
> packets.
>
> Setup:
>
> Tomcat 5.5 -> JK 1.2.30 -> SunOne 6.1sp11
So you're using mod_jk 1.2.30 to connect Tomcat 5.5 and SunOne?
> I tested using Apache2 and the problem does not show up there. Using apache
> is not an option here.
Okay.
> Tomcat to web server through JK connector, same for Sun One and Apache
Is this data /from/ Tomcat /to/ Sun One, or from Sun One /to/ Tomcat?
That is, are we looking at a request or a response? It kind of looks
like a response, but I just want to be sure.
> 0090 20 47 4d 54 00 00 0c 43 6f 6e 74 65 6e 74 2d 54 GMT...Content-T
> 00a0 79 70 65 00 00 08 74 65 78 74 2f 63 73 73 00 00 ype...text/css..
> 00b0 0e 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 00 .Content-Length.
> 00c0 00 05 32 32 33 37 33 00 41 42 1f fc 03 1f f8 40 ..22373.AB.....@
> 00d0 43 48 41 52 53 45 54 20 22 55 54 46 2d 38 22 3b CHARSET "UTF-8";
> 00e0 23 74 70 63 72 7b 62 61 63 6b 67 72 6f 75 6e 64 #tpcr{background
> 00f0 2d 63 6f 6c 6f 72 3a 57 68 69 74 65 3b 6d 61 72 -color:White;mar
> 0100 67 69 6e 3a 31 30 70 78 20 30 20 32 30 70 78 20 gin:10px 0 20px
Can you dump the whole response?
> Browser from Apache
>
> 0120 76 65 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 ve..Content-Type
> 0130 3a 20 74 65 78 74 2f 63 73 73 0d 0a 0d 0a 40 43 : text/css....@c
> 0140 48 41 52 53 45 54 20 22 55 54 46 2d 38 22 3b 23 HARSET "UTF-8";#
> 0150 74 70 63 72 7b 62 61 63 6b 67 72 6f 75 6e 64 2d tpcr{background-
> 0160 63 6f 6c 6f 72 3a 57 68 69 74 65 3b 6d 61 72 67 color:White;marg
> 0170 69 6e 3a 31 30 70 78 20 30 20 32 30 70 78 20 30 in:10px 0 20px 0
Why are the hex offsets different? Differing standard headers? Again,
can you post the whole response?
> Browser from SunOne
>
> 00e0 47 4d 54 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 GMT..Content-Typ
> 00f0 65 3a 20 74 65 78 74 2f 63 73 73 0d 0a 43 6f 6e e: text/css..Con
> 0100 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 32 32 33 tent-Length: 223
> 0110 37 33 0d 0a 54 72 61 6e 73 66 65 72 2d 65 6e 63 73..Transfer-enc
> 0120 6f 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a oding: chunked..
> 0130 0d 0a 31 66 66 38 0d 0a 40 43 48 41 52 53 45 54 ..1ff...@charset
> 0140 20 22 55 54 46 2d 38 22 3b 23 74 70 63 72 7b 62 "UTF-8";#tpcr{b
> 0150 61 63 6b 67 72 6f 75 6e 64 2d 63 6f 6c 6f 72 3a ackground-color:
> 0160 57 68 69 74 65 3b 6d 61 72 67 69 6e 3a 31 30 70 White;margin:10p
> 0170 78 20 30 20 32 30 70 78 20 30 3b 7d 0a 23 74 70 x 0 20px 0;}.#tp
Are all of these dumps from the same response, but at different points
in the process?
I can see that there is a "1ff8" (in text) in that last dump. What is that?
It appears that some component is switching the Transfer-encoding to
"chunked". Do you know if that's intentional?
> The first snippet is from between the web server and tomcat through the JK
> connector. This looks the same for either Apache or SunOne.
>
> The thing to note is line 00c0 where the hex is 1f f8.
Is that a Greek Omicron? Or something else?
> The second snippet is when a browser hits Apache. The thing to note is line
> 0130 where the hex is 0d 0a 0d 0a. (carriage return, line feed, carriage
> return, line feed)
The CR LF CR LF seems to be more likely to be correct.
> The third snippet is when a browser hits SunOne for the same file. Here on
> line 0130 there is 0d 0a 31 66 66 38 0d 0a, notice the extra 4 characters
> between the carriage return/line feeds.
Those 4 extra characters are likely to be the chunk size. 31 66 66 38
is, well, "1ff8", which is 792 in decimal. So, the chunk size is 792
bytes. Did you get 792 bytes after the next CR LF? Again, a complete
response would be helpful in determining what's happening.
> And that is where my problem lies. These characters 1ff8 are showing up in
> the body of the content and is causing errors.
Technically speaking, this is not content: it's header. Your client is
misinterpreting the data it's receiving from the server.
Take a look at http://www.httpwatch.com/httpgallery/chunked/ - the page
is chunked with each line of text in a separate chunk. I think it will
demonstrate what I'm talking about. If you can't view it any other way,
you can do this:
$ telnet www.httpwatch.com 80 > temp.out
GET /httpgallery/chunked/
Connection closed by foreign host.
$ less temp.out
You should see content like this:
[snip]
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: -1
Content-Type: text/html
7b
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
2d
<html xmlns="http://www.w3.org/1999/xhtml";>
[and so on]
9
</body>
9
</html>
2
0
[the 0 indicates the last chunk, which contains no data].
Is this what you're observing, here? If so, I think it's standard
"chunked" response encoding.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwr6J8ACgkQ9CaO5/Lv0PAtdQCcDb5KZkTMsI2bB70B017mgXef
bt4An2qMVVCVuvxD9/NI0Qh63M3N0YiL
=oalw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
