Lars Ingebrigtsen writes: > Robert Pluim writes: > >> one of the consequences of asking the user questions during network >> connection setup is that the server they're trying to connect to might >> have decided to close the connection by the time they've finished >> answering. > > Yes, the NSM should reconnect if the user says "go ahead" to the NSM > warning and the server has closed the connection. The reason that > landed on the back burner is that servers seem to mostly have long > timeouts, so this turned out to be less of a problem in practice than I > expected. (I.e., I don't recall seeing a bug report about this, which > is just plain weird.) Thereʼs this little-known news server called news.gmane.org that has a 10 second timeout :-) Reconnecting immediately works, so itʼs not a big deal. So you'd put this in nsm-verify-connection, without a user option? I donʼt think nsm currently has access to all the connection setup parameters, which is why I put the logic in open-network-stream. Proof-of-concept patch attached (it should really do more checking of what nsm returned). > We could also reverse the logic a bit and have the NSM always shut down > the connection before prompting. This will make network connections > (that prompt an NSM warning) be somewhat slower, but it shouldn't be a > big deal. That seems wasteful. In most cases the connection will complete OK, so why add an extra connection setup for all cases? > In any case, when reconnecting we have to consider whether this would > trigger extra auth-source prompts, which would be annoying, but I have a > feeling like these are mostly done later in the connection process > usually, so it shouldn't be an issue. If youʼre thinking of authentication for SMTP sessions and the like, they'd all arrive after completion of the TLS setup. Robert