https://bz.apache.org/bugzilla/show_bug.cgi?id=64192
--- Comment #6 from Mark Thomas <ma...@apache.org> --- I think I have got to the bottom of this. It relates to reading HTTP/2 frames using asyncIO over TLS. TLS sometimes needs to decrypt more data that the caller requests. This is because data is decrypted in 'blocks' and the call may only have requested part of the next block. This excess data is placed in the read buffer so it is available for the next read. HTTP/2 async reads HTTP/2 frames using a gathering read. It uses one ByteBuffer for the 9 byte header and another for the frame payload. At this point the size of the frame payload is unknown so a bufter is used that is big enough for the largest frame. It is possible that more data is read into the payload buffer than is required. This excess data is returned to the read buffer so it is available for the next read. The problem is that we have two components writing to the read buffer and the code that returns this data assumes the read buffer is empty. Consider the following (thinking purely in terms of decrypted data): - There are 4 TLS "blocks" (A, B, C and D) of data in the socket input buffer - HTTP/2 async triggers a read - The payload buffer is big enough to hold all of blocks A and B and half of block C (C1) - The other half of C (C2) is placed into the read buffer - The HTTP/2 parser only needed block A so block B and C1 are returned to the read buffer - The order of data in the read buffer is now "C2, B, C1". It should be "B, C1, C2" In this instance, "B C1" is a single byte - hence why it looked like an off-by-one error. But it isn't. Returning the correct number of bytes for the TLS read is a separate issue. It is also the case that, if the TLS code puts some data into the read buffer, it will try and put as much as possible into the read buffer. I think this needs to change else there is a risk that the amount of data returned by the HTTP/2 parser will be in excess of the space available in the read buffer. I'm working on a fix. I need to be careful as fixing one of these issues may be sufficient to mask the others and I want to try and avoid that. -- 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
