https://bz.apache.org/bugzilla/show_bug.cgi?id=57674
--- Comment #9 from Rainer Jung <rainer.j...@kippdata.de> --- (In reply to Christopher Schultz from comment #7) > Yes, all occurrences of the garbled bytes are the same set of replacement > bytes: > > 41 42 20 04 03 02 00 > A B sp eot etx sp nul AB is the start on a tomcat-to-web-server-packet. The 0x20 and 0x04 are the length of the packet, so here it is 8196 bytes. Next is packet type 0x03 which is a body chunk packet. Next is 0x02 0x00 but I think it actually is 0x20 0x00 (see your previous post) which is the chunk size, so here it is 8KB. The rest is the raw data. So it looks like the TC AJP connector has somehow framed the response into to small packets not respecting the configured packet size. It would be interesting though to see the data before these bytes. Namely whether the previous AJP packet had the right size, so the "AB" starts right after the previous packet and the error is on the reassembling side (mod_jk), or whether th previous packet announced more data than it actually sended and then "suddenly" a new packet started. Regards, Rainer -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
