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?
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
