Daniel Stenberg wrote:
> If libssh2 skips the waiting for the remote EOF, what happens?
> Peter's fix added both sending and waiting, and I think what we
> suggest is that we drop the waiting.
I don't think that this is for the best. The topic recently came up
also on the OpenSSH list:
From this wording (and the RFC) it is clear to me that it is not so
polite to CLOSE without first sending and receiving EOF - even if it
*is* allowed. To me it makes a lot of sense to first clean up, and
then CLOSE. So I implemented what I consider polite and more correct
client behavior. And, OpenSSH works like that.
commit 0ecd0eb37c02216bcb0c34797beb645bf14cf4bb removed the waiting
for EOF and I believe this change originates in a somewhat different
philosophy - one of more forcibly terminating the connection and
shutting down more like *NOW*.
I can understand the desire to not want to care about the server, but
I don't think that it is the best we can do.
It seems a bad idea to consciously do something in libssh2 that
*could* upset servers, even though it is allowed by protocol. I've
seen several sensitive servers mentioned on the OpenSSH list, and in
any case I think it's best to take as few risks as possible.
So, I do not think that it is what libssh2 should do by default!
Actually - I don't think libssh2 should do it at all.
If the calling app wants to just close down ASAP then they could
close() the socket and move on. Or even exit().
In summary I don't think we should encourage apps to CLOSE early.
Be tolerant on input (API) but strict with output (protocol) is one
way to explain it.
If there are problems with two-way EOF then let's investigate them
thoroughly and learn what the problem is, rather than yank code that
happens to trigger the symptom.
I guess noone else will look into what the actual problem is with the
testcase, so I'll try to do it, but I'm not sure when I'll find time.
Received on 2010-04-15