 | 1 | initial version |
Without decrypting the data it would be very difficult to determine what is going on at the application level. Are you able to reproduce the error with Edge, Firefox or Chrome with SSLKEYLOGFILE environment variable to collect the TLS session keys?
I'm assuming the session that ends normal with FINs (tcp.stream==1) is working and the one that ends with the RST (tcp.stream==2) is not working. Looking at the encrypted packets, I see the communication ending with a 29 bytes TLS record in the working and non-working situation. As TLS reconds can only be 16384 bytes long cleartext and I see TLS records of 16408 bytes, I assume TLS has added 24 bytes to each record (which is quite common). This would mean the last TLS record of each tranfser contains 29 -24 = 5 bytes of unencrypted payload. With a chunked HTTP response, the last chunk has a length marker of '0' followed by \r\n\r\n. Which is 5 bytes too. So I suspect that HTTP object has ben transferred fully (from the HTTP client/server point of view).
My guess would be that the HTTP object itself has been transferred fine (at HTTP, TLS and TCP level), but that the content of the HTTP object is not acceptable by the client. Again, decryption of the traffic is needed to properly see what is going on.
