During his review in bug 111384 comment 77 Bob Relyea proposed additional functionality for the new SSL thread added with that bug. The proposed additional functionality seems not necessary for Mozilla's own SSL networking to work correctly, and has therefore been postponed to be done at a later time, and memorized in this separate enhancement request. Bob said: 1) recv and send can easily be "fully" supported using the existing read and write interfaces. SSL only supports the PEEK flag, for recv, so in the non-peek case (the only case not currently supported by this function) we can just call our read function. I'm not sure which flags SSL supports for send, so we may want to pass the flag and call send. SSL maps write to a send with no flags). 2) Pluggins handshaking as servers. There is an existing bug that is trying to add this functionality (it does not yet exist). In order for this to work accept and listen will have to be added. It should be safe to call the SSL functions directly for these as SSL handshakes are only initiated on reads and writes. 3) Short writes. Currently the code starts a write, but tells the application no data was written. For most well behaved applications, this means the application will retry the original data. It is possible an application may decide not to retry the data, however, in which case there will be and inconsistant state between the application at the server it is talking to. One way to get around this is to return a partial write back to the application, so the application knows that most of the data has already been sent, but it still needs to retry the rest of the buffer. None of these are issues for Necko's usage. Issue 2 most likely will not affect existing pluggins since that support does not exist, and issue 3 is pretty rare.

In comment 0, Bob wrote: > 3) Short writes. Currently the code starts a write, but tells the application > no data was written. I wonder which code Bob meant by "the code". This does not describe how NSS works on non-blocking sockets, so I wonder what code it does describe. > For most well behaved applications, this means the application will retry > the original data. It is possible an application may decide not to retry > the data, however, in which case there will be an inconsistant state > between the application at the server it is talking to. NSS will detect if the appliation retries different data. > One way to get around this is to return a partial write back to the > application, so the application knows that most of the data has already > been sent, but it still needs to retry the rest of the buffer. That is what NSS does. And, as mentioned before, NSS detects if the app's retry sends different data than on the previous try. So, perhaps Bob is describing PSM code?

reassign bug owner. mass-update-kaie-20120918

Plugins are going away, so it doesn't look like parts 1 and 2 are relevant any longer. For part 3, any remaining short write issues will be handled in bug 705755.

Just FYI, anything regarding the "SSL thread" was rendered moot by bug 674147.

OK - thanks.