https://bz.apache.org/bugzilla/show_bug.cgi?id=66488
--- Comment #5 from Fabian Günter <n4zr...@gmail.com> --- (In reply to Konstantin Kolinko from comment #3) > (In reply to Fabian Günter from comment #0) > > In 9.0.71 the code for MessageBytes#toBytes was changed to call the newly > > introduced MessageBytes#toSimpleBytes method which incorrectly assumes that > > byteC.getBuffer's retured array is a copy of the original request string > > Honestly, I do not follow your explanation. > > > A byteC.getBuffer() call returns ByteChunk.buff. That is a byte[] array that > is owned by that ByteChunk. The buff field in ByteChunk is initialized as > null (by ByteChunk() constructor) or as a "new byte[initial]" (by other > constructor calling allocate(..)). > > The only way that it may be changed to an externally created array is via a > ByteChunk.setBytes(...) call. What call to ByteChunk.setBytes(...) passes > such a shared array? Well there are several places in Tomcat's code calling exactly what you said here, ByteChunk.setBytes, especially in Http11InputBuffer which is the class I'm referring to. The class has one single byteBuffer that gets shared to request, method, authentication, etc. via the .array method, as Mark confirmed. > > > Every instance of MessageByte created early in the request processing > > gets passed a reference to the same byte array > > (which is documented in java.nio.ByteBuffer#array) > > I do not see such documentation. The javadoc of that method says "Returns > the byte array that backs this buffer". > > Do we have several ByteBuffer instances that are backed by the same array? > Do we have the same ByteBuffer instance reused somewhere? > You should read more than the first line of the JavaDoc: ... Modifications to this buffer's content will cause the returned array's content to be modified, and vice versa. ... (see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#array() ). The byte buffer of the request is shared by all ByteChunks which is quite obvious by debugging the code. > > To be safe, I reviewed documentation for > java.nio.charset.Charset.encode(...) method that is called by > MessageBytes.toBytes(). It falls through to > java.nio.charset.CharsetEncoder.encode(CharBuffer) which is documented as > "Returns: A newly-allocated byte buffer". I know that CharsetEncoder class > is not thread-safe, but no ByteBuffer sharing occurs here. > In case of odd "data mixup" errors between requests (such as one observed > > here), > it is recommended to set discardFacades="true" on a <Connector>. > https://tomcat.apache.org/tomcat-9.0-doc/config/http.html > In Tomcat 9.0.72 the discardFacades attribute defaults to "false". > In Tomcat 10.1.x and later it defaults to "true". As stated in my bug report, I'm reproducing this locally with a single request. No 'data mixup' here. -- 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