Thus said Kelly Dean on Fri, 09 Jan 2015 08:39:35 +0000: > HTTPS can't prevent a proxy from dropping packets, including all > packets after a certain number of bytes for the connection. It also > doesn't prevent bogus reset packets, though a properly-designed secure > transport protocol (i.e. not SSL) could prevent them.
Right, I'm still not sure how a dropped packet would cause this unless the SSL transport treated the lost packet as the end of the stream and gave Fossil what it had (an incomplete response). > Did you get the partially-cloned repository files that I posted? I did. I looked at the repository and I could see that the repository had a some of the artifacts. It had the project configuration which means it went 2 rounds (confirmed by the output), but it didn't have a project-code, which seems only possible if it didn't receive a project-code in any push card in the response. But if it didn't get a push card, it likely also didn't get the clone_seqno, and yet, it did complete the clone and rebuild, which means there were no reported errors. I suppose it's possible that it went 2 round-trips, got the headers for the third round-trip, and then the SSL transport returned no data. If the second response was truncated before getting the push card and before getting clone_seqno, the third response might cause Fossil to drop out of the clone loop. This explanation seems to fit the facts, but reproducing it is a pain. Let me see if I can cause what I've just stated above to happen. :-) If this is the case, then checking the response data size against the Content-length header would indeed ameliorate the problem. Thanks for your response. Andy -- TAI64 timestamp: 4000000054aff84e _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
