You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2010/07/01 03:00:15 UTC
Re: JK connector and extra characters showing up
-----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
Re: JK connector and extra characters showing up
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 6/30/2010 11:18 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Re: JK connector and extra characters showing up
>>
>> Those 4 extra characters are likely to be the chunk size. 31 66 66 38
>> is, well, "1ff8", which is 792 in decimal.
>
> Not on my calculator; would you believe 8184 in decimal? There's an extremely low probability of having a decimal value containing fewer digits than its hex equivalent...
Hmm. It appears I was sleepy and lazy altogether.
8 + 16*15 + 32 * 15 + 64 * 1 = 792
but the LHS is complete malarkey. At least my arithmetic was correct ;)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwuiDcACgkQ9CaO5/Lv0PA50gCfTIFZAozmYPnf2mfIPjc7c9GE
e+MAn0rDAb6XYpKsf4eKdDbJlh3iZ2lT
=O2b0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JK connector and extra characters showing up
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Re: JK connector and extra characters showing up
>>
>> Those 4 extra characters are likely to be the chunk size. 31 66 66 38
>> is, well, "1ff8", which is 792 in decimal.
>
> Not on my calculator; would you believe 8184 in decimal? There's an extremely low probability of having a decimal value containing fewer digits than its hex equivalent...
>
Guys,
is it me, or you, that is getting a bit confused here ?
First of all, what /are/ these captures ?
From re-reading David's original post :
...
Here are some snippets of packet captures (tcpdump) to show what I mean.
...
Tomcat to web server through JK connector, same for Sun One and Apache
...
It is not really clear where this data was captured. Between Tomcat and the jk connector
(emebedded in the webserver) ? In that case, we are looking at binary data in AJP
protocol format, not at HTTP data per se. Not so ?
And if so, what's to tell what this "1f f8" might really be there for ?
Apologies if I'm the confused one.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JK connector and extra characters showing up
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: JK connector and extra characters showing up
>
> Those 4 extra characters are likely to be the chunk size. 31 66 66 38
> is, well, "1ff8", which is 792 in decimal.
Not on my calculator; would you believe 8184 in decimal? There's an extremely low probability of having a decimal value containing fewer digits than its hex equivalent...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: JK connector and extra characters showing up
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Brown [mailto:captkiddo@gmail.com]
> Subject: Re: JK connector and extra characters showing up
>
> Now here's what I'm seeing. In dump A (tomcat jk) in
> packet 2 at line 00c0 look at the end of the line's
> hex. It's 03 1f f8 40. Pay attention to the 1f f8,
> it shows up latter.
Rainer already told you what the problem is; the webapp is violating the HTTP spec:
> > It *seems* your application sends a Content-Length header
> > and does chunked encoding at the same time. That's an
> > invalid response. Your Apache snippet shows that it clears
> > that up by dropping the Content-Length header. The SunONE
> > snippet shows that combination send both variants and
> > confuses the client.
> >
> > The root cause though would sit in your webapp, which needs
> > to decide to send Content-Length only if it is not doing
> > Transfer-Encoding chunked.
httpd cleans up your error, but SunONE isn't that smart. Fix your webapp.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JK connector and extra characters showing up
Posted by David Brown <ca...@gmail.com>.
First let me thank everyone for looking at this. Now I'll try to answer some
of the questions and clear up the confusion (if I can).
All these dumps are from responses and not request. I'll post more complete
dumps at he end of this message.
The first one is the communications between tomcat and the web server, AJP
protocol. Since it was the same for both Apache and SunOne I only posted one
of them.
The second and third are from between a browser and the web server, Apache
and SunOne. The only difference is the web server and the JK connector
(mod_jk vs jk_nsapi). Same tomcat, application, file (style sheet), browser,
servers, and network.
Now here's what I'm seeing. In dump A (tomcat jk) in packet 2 at line 00c0
look at the end of the line's hex. It's 03 1f f8 40. Pay attention to the 1f
f8, it shows up latter.
In dump B (Apache) in packet 2 at line 0130 towards the end of the line of
hex is 0d 0a 0d 0a (CR LF CR LF). Normal
Now in dump C (SunOne) in packet 2 at line 0130 towards the beginning is 0d
0a 31 66 66 38 0d 0a or CR LF 1f f8 CR LF.
It seems to me that the hex 1f f8 seen the first dump is making its way into
the output in the third dump. I'm thinking there's a difference in the
behavior of the JK connector between Apache and SunOne.
Now for some background. We've been running this setup for 6 or 7 years now
without a problem. Browsers, wget, curl, Squid are not affected by this,
maybe they see the break between header and body as the second CR LF.
Recently we've tried using Varnish as our cache and it seems to see the
break as the first CR LF and included the 1f f8 in the body of the response.
This is where we are seeing errors.
Yes, i am posting to Varnish's mailing list to to see if they can help. So I
ether need consistent output from the JK connector or for Varnish to break
the header/body at the second CR LF.
Here's more dump for your reading pleasure....
A) Tomcat to web server (response) AJP
Packet #1
0000 0e 91 b2 32 3b 90 00 03 ba ec ea 76 08 00 45 00 ...2;......v..E.
0010 01 eb 4e 1a 40 00 40 06 00 00 c0 a8 b6 20 c0 a8 ..N.@.@...... ..
0020 b6 1e 80 7c 1f 49 ff 04 18 db e5 67 e9 83 50 18 ...|.I.....g..P.
0030 c1 e8 00 00 00 00 12 34 01 bf 02 02 00 08 48 54 .......4......HT
0040 54 50 2f 31 2e 31 00 00 2b 2f 63 6f 6d 70 6f 6e TP/1.1..+/compon
0050 65 6e 74 73 2f 72 65 73 6f 75 72 63 65 73 2f 63 ents/resources/c
0060 73 73 2f 74 70 63 2d 61 67 67 72 65 67 61 74 65 ss/tpc-aggregate
0070 2e 63 73 73 00 00 0e 31 39 32 2e 31 36 38 2e 32 .css...192.168.2
0080 31 30 2e 36 35 00 ff ff 00 08 77 65 62 61 70 70 10.65.....webapp
0090 2d 66 00 00 50 00 00 09 a0 0b 00 08 77 65 62 61 -f..P.......weba
00a0 70 70 2d 66 00 a0 0e 00 61 4d 6f 7a 69 6c 6c 61 pp-f....aMozilla
00b0 2f 35 2e 30 20 28 4d 61 63 69 6e 74 6f 73 68 3b /5.0 (Macintosh;
00c0 20 55 3b 20 49 6e 74 65 6c 20 4d 61 63 20 4f 53 U; Intel Mac OS
00d0 20 58 20 31 30 2e 35 3b 20 65 6e 2d 55 53 3b 20 X 10.5; en-US;
00e0 72 76 3a 31 2e 39 2e 31 2e 31 30 29 20 47 65 63 rv:1.9.1.10) Gec
00f0 6b 6f 2f 32 30 31 30 30 35 30 34 20 46 69 72 65 ko/20100504 Fire
0100 66 6f 78 2f 33 2e 35 2e 31 30 00 a0 01 00 3f 74 fox/3.5.10....?t
0110 65 78 74 2f 68 74 6d 6c 2c 61 70 70 6c 69 63 61 ext/html,applica
0120 74 69 6f 6e 2f 78 68 74 6d 6c 2b 78 6d 6c 2c 61 tion/xhtml+xml,a
0130 70 70 6c 69 63 61 74 69 6f 6e 2f 78 6d 6c 3b 71 pplication/xml;q
0140 3d 30 2e 39 2c 2a 2f 2a 3b 71 3d 30 2e 38 00 00 =0.9,*/*;q=0.8..
0150 0f 41 63 63 65 70 74 2d 4c 61 6e 67 75 61 67 65 .Accept-Language
0160 00 00 0e 65 6e 2d 75 73 2c 65 6e 3b 71 3d 30 2e ...en-us,en;q=0.
0170 35 00 00 0f 41 63 63 65 70 74 2d 45 6e 63 6f 64 5...Accept-Encod
0180 69 6e 67 00 00 0c 67 7a 69 70 2c 64 65 66 6c 61 ing...gzip,defla
0190 74 65 00 00 0e 41 63 63 65 70 74 2d 43 68 61 72 te...Accept-Char
01a0 73 65 74 00 00 1e 49 53 4f 2d 38 38 35 39 2d 31 set...ISO-8859-1
01b0 2c 75 74 66 2d 38 3b 71 3d 30 2e 37 2c 2a 3b 71 ,utf-8;q=0.7,*;q
01c0 3d 30 2e 37 00 00 0a 4b 65 65 70 2d 41 6c 69 76 =0.7...Keep-Aliv
01d0 65 00 00 03 33 30 30 00 a0 06 00 0a 6b 65 65 70 e...300.....keep
01e0 2d 61 6c 69 76 65 00 a0 08 00 01 30 00 06 00 07 -alive.....0....
01f0 77 6f 72 6b 65 72 36 00 ff worker6..
Packet #2
0000 00 03 ba ec ea 76 0e 91 b2 32 3b 90 08 00 45 00 .....v...2;...E.
0010 05 dc 5b f5 40 00 3c 06 ef 96 c0 a8 b6 1e c0 a8 ..[.@.<.........
0020 b6 20 1f 49 80 7c e5 67 e9 83 ff 04 1a 9e 50 10 . .I.|.g......P.
0030 c1 e8 1b f3 00 00 41 42 00 8e 04 00 c8 00 02 4f ......AB.......O
0040 4b 00 00 04 00 04 45 54 61 67 00 00 17 57 2f 22 K.....ETag...W/"
0050 32 32 33 37 33 2d 31 32 37 37 34 39 39 37 33 39 22373-1277499739
0060 30 30 30 22 00 00 0d 4c 61 73 74 2d 4d 6f 64 69 000"...Last-Modi
0070 66 69 65 64 00 00 1d 46 72 69 2c 20 32 35 20 4a fied...Fri, 25 J
0080 75 6e 20 32 30 31 30 20 32 31 3a 30 32 3a 31 39 un 2010 21:02:19
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
0110 30 3b 7d 0a 23 74 70 63 72 20 68 33 7b 66 6f 6e 0;}.#tpcr h3{fon
0120 74 2d 73 69 7a 65 3a 32 36 70 78 3b 6d 61 72 67 t-size:26px;marg
0130 69 6e 2d 62 6f 74 74 6f 6d 3a 32 30 70 78 3b 66 in-bottom:20px;f
0140 6f 6e 74 2d 77 65 69 67 68 74 3a 62 6f 6c 64 3b ont-weight:bold;
... rest of style sheet
B) From Apache to Browser (response) HTTP
Packet #1
0000 00 03 ba ec ea 76 00 0f a3 e9 e6 ea 08 00 45 00 .....v........E.
0010 01 d1 11 0b 40 00 3e 06 20 69 c0 a8 d2 41 c0 a8 ....@.>. i...A..
0020 b6 20 c9 b8 00 50 d7 94 2f 1b 01 de ff 33 80 18 . ...P../....3..
0030 ff ff 3a 97 00 00 01 01 08 0a 11 25 86 de 04 31 ..:........%...1
0040 b7 70 47 45 54 20 2f 63 6f 6d 70 6f 6e 65 6e 74 .pGET /component
0050 73 2f 72 65 73 6f 75 72 63 65 73 2f 63 73 73 2f s/resources/css/
0060 74 70 63 2d 61 67 67 72 65 67 61 74 65 2e 63 73 tpc-aggregate.cs
0070 73 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 s HTTP/1.1..Host
0080 3a 20 77 65 62 61 70 70 2d 66 0d 0a 55 73 65 72 : webapp-f..User
0090 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f -Agent: Mozilla/
00a0 35 2e 30 20 28 4d 61 63 69 6e 74 6f 73 68 3b 20 5.0 (Macintosh;
00b0 55 3b 20 49 6e 74 65 6c 20 4d 61 63 20 4f 53 20 U; Intel Mac OS
00c0 58 20 31 30 2e 35 3b 20 65 6e 2d 55 53 3b 20 72 X 10.5; en-US; r
00d0 76 3a 31 2e 39 2e 31 2e 31 30 29 20 47 65 63 6b v:1.9.1.10) Geck
00e0 6f 2f 32 30 31 30 30 35 30 34 20 46 69 72 65 66 o/20100504 Firef
00f0 6f 78 2f 33 2e 35 2e 31 30 0d 0a 41 63 63 65 70 ox/3.5.10..Accep
0100 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c 61 70 70 t: text/html,app
0110 6c 69 63 61 74 69 6f 6e 2f 78 68 74 6d 6c 2b 78 lication/xhtml+x
0120 6d 6c 2c 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 ml,application/x
0130 6d 6c 3b 71 3d 30 2e 39 2c 2a 2f 2a 3b 71 3d 30 ml;q=0.9,*/*;q=0
0140 2e 38 0d 0a 41 63 63 65 70 74 2d 4c 61 6e 67 75 .8..Accept-Langu
0150 61 67 65 3a 20 65 6e 2d 75 73 2c 65 6e 3b 71 3d age: en-us,en;q=
0160 30 2e 35 0d 0a 41 63 63 65 70 74 2d 45 6e 63 6f 0.5..Accept-Enco
0170 64 69 6e 67 3a 20 67 7a 69 70 2c 64 65 66 6c 61 ding: gzip,defla
0180 74 65 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 te..Accept-Chars
0190 65 74 3a 20 49 53 4f 2d 38 38 35 39 2d 31 2c 75 et: ISO-8859-1,u
01a0 74 66 2d 38 3b 71 3d 30 2e 37 2c 2a 3b 71 3d 30 tf-8;q=0.7,*;q=0
01b0 2e 37 0d 0a 4b 65 65 70 2d 41 6c 69 76 65 3a 20 .7..Keep-Alive:
01c0 33 30 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 300..Connection:
01d0 20 6b 65 65 70 2d 61 6c 69 76 65 0d 0a 0d 0a keep-alive....
Packet #2
0000 00 0f a3 e9 e6 ea 00 03 ba ec ea 76 08 00 45 00 ...........v..E.
0010 05 8c 6c 0a 40 00 3c 06 00 00 c0 a8 b6 20 c0 a8 ..l.@.<...... ..
0020 d2 41 00 50 c9 b8 01 de ff 33 d7 94 30 b8 80 10 .A.P.....3..0...
0030 c0 60 00 00 00 00 01 01 08 0a 04 31 b7 73 11 25 .`.........1.s.%
0040 86 de 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f ..HTTP/1.1 200 O
0050 4b 0d 0a 44 61 74 65 3a 20 57 65 64 2c 20 33 30 K..Date: Wed, 30
0060 20 4a 75 6e 20 32 30 31 30 20 31 38 3a 34 39 3a Jun 2010 18:49:
0070 34 31 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 GMT..Server:
0080 41 70 61 63 68 65 0d 0a 45 54 61 67 3a 20 57 2f Apache..ETag: W/
0090 22 32 32 33 37 33 2d 31 32 37 37 34 39 39 37 33 "22373-127749973
00a0 39 30 30 30 22 0d 0a 4c 61 73 74 2d 4d 6f 64 69 9000"..Last-Modi
00b0 66 69 65 64 3a 20 46 72 69 2c 20 32 35 20 4a 75 fied: Fri, 25 Ju
00c0 6e 20 32 30 31 30 20 32 31 3a 30 32 3a 31 39 20 n 2010 21:02:19
00d0 47 4d 54 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e GMT..Content-Len
00e0 67 74 68 3a 20 32 32 33 37 33 0d 0a 4b 65 65 70 gth: 22373..Keep
00f0 2d 41 6c 69 76 65 3a 20 74 69 6d 65 6f 75 74 3d -Alive: timeout=
0100 35 2c 20 6d 61 78 3d 31 30 30 0d 0a 43 6f 6e 6e 5, max=100..Conn
0110 65 63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 ection: Keep-Ali
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
0180 3b 7d 0a 23 74 70 63 72 20 68 33 7b 66 6f 6e 74 ;}.#tpcr h3{font
0190 2d 73 69 7a 65 3a 32 36 70 78 3b 6d 61 72 67 69 -size:26px;margi
01a0 6e 2d 62 6f 74 74 6f 6d 3a 32 30 70 78 3b 66 6f n-bottom:20px;fo
01b0 6e 74 2d 77 65 69 67 68 74 3a 62 6f 6c 64 3b 64 nt-weight:bold;d
... rest of style sheet
C) From SunOne to Browser (response) HTTP
Packet #1
0000 00 14 4f c7 1a 1e 00 0f a3 e9 e6 eb 08 00 45 00 ..O...........E.
0010 01 d7 c4 cf 40 00 3e 06 6d 9b c0 a8 d2 41 c0 a8 ....@.>.m....A..
0020 b5 23 e8 64 00 50 69 9d 8f cb 9d de f6 cc 80 18 .#.d.Pi.........
0030 80 40 34 8a 00 00 01 01 08 0a 11 22 0d a3 4f 50 .@4........"..OP
0040 dc 8a 47 45 54 20 2f 63 6f 6d 70 6f 6e 65 6e 74 ..GET /component
0050 73 2f 72 65 73 6f 75 72 63 65 73 2f 63 73 73 2f s/resources/css/
0060 74 70 63 2d 61 67 67 72 65 67 61 74 65 2e 63 73 tpc-aggregate.cs
0070 73 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 s HTTP/1.1..Host
0080 3a 20 31 39 32 2e 31 36 38 2e 31 38 31 2e 33 35 : 192.168.181.35
0090 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f ..User-Agent: Mo
00a0 7a 69 6c 6c 61 2f 35 2e 30 20 28 4d 61 63 69 6e zilla/5.0 (Macin
00b0 74 6f 73 68 3b 20 55 3b 20 49 6e 74 65 6c 20 4d tosh; U; Intel M
00c0 61 63 20 4f 53 20 58 20 31 30 2e 35 3b 20 65 6e ac OS X 10.5; en
00d0 2d 55 53 3b 20 72 76 3a 31 2e 39 2e 31 2e 31 30 -US; rv:1.9.1.10
00e0 29 20 47 65 63 6b 6f 2f 32 30 31 30 30 35 30 34 ) Gecko/20100504
00f0 20 46 69 72 65 66 6f 78 2f 33 2e 35 2e 31 30 0d Firefox/3.5.10.
0100 0a 41 63 63 65 70 74 3a 20 74 65 78 74 2f 68 74 .Accept: text/ht
0110 6d 6c 2c 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 ml,application/x
0120 68 74 6d 6c 2b 78 6d 6c 2c 61 70 70 6c 69 63 61 html+xml,applica
0130 74 69 6f 6e 2f 78 6d 6c 3b 71 3d 30 2e 39 2c 2a tion/xml;q=0.9,*
0140 2f 2a 3b 71 3d 30 2e 38 0d 0a 41 63 63 65 70 74 /*;q=0.8..Accept
0150 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 2d 75 73 -Language: en-us
0160 2c 65 6e 3b 71 3d 30 2e 35 0d 0a 41 63 63 65 70 ,en;q=0.5..Accep
0170 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 67 7a 69 70 t-Encoding: gzip
0180 2c 64 65 66 6c 61 74 65 0d 0a 41 63 63 65 70 74 ,deflate..Accept
0190 2d 43 68 61 72 73 65 74 3a 20 49 53 4f 2d 38 38 -Charset: ISO-88
01a0 35 39 2d 31 2c 75 74 66 2d 38 3b 71 3d 30 2e 37 59-1,utf-8;q=0.7
01b0 2c 2a 3b 71 3d 30 2e 37 0d 0a 4b 65 65 70 2d 41 ,*;q=0.7..Keep-A
01c0 6c 69 76 65 3a 20 33 30 30 0d 0a 43 6f 6e 6e 65 live: 300..Conne
01d0 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 ction: keep-aliv
01e0 65 0d 0a 0d 0a
Packet #2
0000 02 12 f2 7c b2 33 00 14 4f c7 1a 1e 08 00 45 00 ...|.3..O.....E.
0010 05 8c 87 bf 40 00 40 06 00 00 c0 a8 b5 23 c0 a8 ....@.@......#..
0020 d2 41 00 50 e8 64 9d de f6 cc 69 9d 91 6e 80 10 .A.P.d....i..n..
0030 25 68 0e 35 00 00 01 01 08 0a 4f 50 dc 8c 11 22 %h.5......OP..."
0040 0d a3 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f ..HTTP/1.1 200 O
0050 4b 0d 0a 53 65 72 76 65 72 3a 20 53 75 6e 2d 4f K..Server: Sun-O
0060 4e 45 2d 57 65 62 2d 53 65 72 76 65 72 2f 36 2e NE-Web-Server/6.
0070 31 0d 0a 44 61 74 65 3a 20 57 65 64 2c 20 33 30 1..Date: Wed, 30
0080 20 4a 75 6e 20 32 30 31 30 20 31 32 3a 33 30 3a Jun 2010 12:30:
0090 30 33 20 47 4d 54 0d 0a 45 54 61 67 3a 20 57 2f 03 GMT..ETag: W/
00a0 22 32 32 33 37 33 2d 31 32 37 37 34 39 39 37 33 "22373-127749973
00b0 39 30 30 30 22 0d 0a 4c 61 73 74 2d 4d 6f 64 69 9000"..Last-Modi
00c0 66 69 65 64 3a 20 46 72 69 2c 20 32 35 20 4a 75 fied: Fri, 25 Ju
00d0 6e 20 32 30 31 30 20 32 31 3a 30 32 3a 31 39 20 n 2010 21:02:19
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
0180 63 72 20 68 33 7b 66 6f 6e 74 2d 73 69 7a 65 3a cr h3{font-size:
0190 32 36 70 78 3b 6d 61 72 67 69 6e 2d 62 6f 74 74 26px;margin-bott
01a0 6f 6d 3a 32 30 70 78 3b 66 6f 6e 74 2d 77 65 69 om:20px;font-wei
01b0 67 68 74 3a 62 6f 6c 64 3b 64 69 73 70 6c 61 79 ght:bold;display
... rest of style sheet
On Thu, Jul 1, 2010 at 4:59 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 01.07.2010 03:00, Christopher Schultz wrote:
>
>> -----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.
>>
>
> It *seems* your application sends a Content-Length header and does chunked
> encoding at the same time. That's an invalid response. Your Apache snippet
> shows that it clears that up by dropping the Content-Length header. The
> SunONE snippet shows that combination send both variants and confuses the
> client.
>
> The root cause though would sit in your webapp, which needs to decide to
> send Content-Length only if it is not doing Transfer-Encoding chunked.
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: JK connector and extra characters showing up
Posted by Rainer Jung <ra...@kippdata.de>.
On 01.07.2010 03:00, Christopher Schultz wrote:
> -----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.
It *seems* your application sends a Content-Length header and does
chunked encoding at the same time. That's an invalid response. Your
Apache snippet shows that it clears that up by dropping the
Content-Length header. The SunONE snippet shows that combination send
both variants and confuses the client.
The root cause though would sit in your webapp, which needs to decide to
send Content-Length only if it is not doing Transfer-Encoding chunked.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org