On 02/07/2021 13:09, Mark Thomas wrote:
On 02/07/2021 12:43, André van der Lugt wrote:

I finally managed to create a decrypted Wireshark capture with injected TLS session keys, will send it in a direct message due to size. I hope it provides the information needed.

Thanks. I have the file. I'll hopefully have time to look at this later today.

Thanks for the trace.

I've spent most of the day reviewing it with the following conclusions:

1. Out of the 10 streams included in the trace, it is stream 2 that is of interest.

2. There is a lot of out of order packets in steam 2 - to the point that Wireshark appears to be unable to follow the stream and decrypt everything (although that doesn't appear to be an issue at this stage).

3. The response pauses about 10KB from the end. After 10s there is a TCP keep alive ping/pong and after a further 4s the remaining 10KB is received.

My original theory (an inconsistent content-length header or chunk size) looks to be wrong.

Based on the observations above, it looks like Tomcat might not be flushing the final part of the response after the application has written it. It is only being flushed when the connection is closed.

I'll see if I can find a way to recreate the issue locally but what would be really helpful would be a test WAR that demonstrates the issue. Given this seems to be triggered by static resources, are you able to create a cut-down version of your app that exhibits the issue that you could share (privately if necessary)?

Other questions that come to mind:

1. Was the network trace created from a client connected directly to Tomcat or was there a proxy / firewall / something else between the client and Tomcat?

2. Where was the trace collected from? On the client? On the server? Somewhere else?



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to