NSS tool tstclnt offers parameter -r, which requests that tstclnt performs re-handshake(s) after the initial handshake. However, the currently implementation will perform the re-handshake(s) immediately after having completed the initial handshake, before any encapsulated data bytes are being transferred. I wonder, might a server allow a rehandshake at this time, but forbid a re-handshake as soon as data has been transferred? I have implemented a new option -R, that will: - do the initial handshake - send a single data byte to the server - do the re-handshake - continue
Comment on attachment 522149 [details] [diff] [review] Patch v1 Not urgent. If you have thoughts, let me know. I made this, to make sure my test results for sites client-initiated-renego enabled are really correct.
Created attachment 540176 [details] [diff] [review] Patch v2 This is a better patch, that makes it easier to test whether a server actually accepts a renegotiation request, completes another handshake, and sends data in the new session.
Kai, could you either: 1) attach a cvs diff patch for review (preferable). or 2) attach a diff -u 15 or diff -c 15. This makes it easier to see the context. (If you attack a cvs diff, then the diff tool knows how to fetch the original source so I can expand it myself. bob
Created attachment 540566 [details] [diff] [review] Patch v9 Lots of additional changes. I wanted verbose reporting of what's going on, but the huge amount of poll status messages were distracting. I invented a separate -P option for verbose poll reporting. I invented a new option -H, only used in combination with new -R. If -H is given, then all server responses prior to the renegotiation is suppressed. This is helpful to see what data the server responds after the handshake. The new test strategy of -R is: - start handshake - send 1 data byte - request a second handshake - wait until the second handshake has completed - send the remaining bytes of the http request - receive the response
Kai, is this patch ready for review? I think this would be helpful for testing bug 542832 and maybe bug 676729, at least.