https://bz.apache.org/bugzilla/show_bug.cgi?id=57674
--- Comment #11 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Rainer Jung from comment #9) > (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. This is starting to make a lot of sense, now. > 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. Yes, the "02" was a typo: it should of course be "20" for a space. So it looks like maybe the underlying AJP protocol component has the problem: it appears to be clobbering response message bytes with its own packet-headers... packet headers that don't need to be added to the response bytes because there is still plenty of space left in the current AJP packet. > So it looks like the TC AJP connector has somehow framed the response into > to small packets not respecting the configured packet size. That would be okay, as long as the AJP headers weren't clobbering content. :) Introducing superfluous packets would be okay, even if it were a little inefficient. > 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. I can enable trace logging at the web server level. Let me get this working on an isolated instance where nobody else will fill-up my logs with extraneous logging. -- 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
