tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: JK connector and extra characters showing up
Date Thu, 01 Jul 2010 01:00:15 GMT
-----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  ..1ff8..@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message