On Tue, Mar 19, 2013 at 08:43:55PM +0100, J??r??mie Courr??ges-Anglas wrote:
> Otto Moerbeek <[email protected]> writes: > > > On Tue, Mar 19, 2013 at 03:16:50PM -0400, Ted Unangst wrote: > > > >> OK, thanks, I think I get it. Let me summarize: > >> > >> nc currently calls shutdown() when it gets EOF on input. This is the > >> right thing to do, because that's how well written network clients > >> indicate end of input. Some broken servers, however, treat shutdown as > >> a disconnect and abort the connection. > > > > Right. > > > >> > >> nc does not have a bug, but as a practical matter, it would be nice to > >> interoperate with buggy servers. To that end, an option to disable the > >> default shutdown() behavior is proposed. > >> > >> End of summary. Correct so far? > > > > Yes, but there is another thing also: gnu netcat. It does not do a > > shutdown. I think in this case it would be a good thing to be > > compatible. > > Quite honestly I don't think that changing the default just to be > compatible is a good idea here. The default behavior makes a lot of > sense to me, and I would expect it from any nc version. > > It would be rather weird to have OpenBSD change the default behavior of > its netcat version and then see the GNU folks doing the opposite change > because they prefer it and don't see a need to maintain compatibility > (which is what the GNU project has done for lots of software). The oldest version of netcat also did not do shutdown on EOF on stdin. See http://nc110.sourceforge.net/ The shutdown behaviour was introduced in our netcat about ten year ago. -Otto > > BTW, reading the various pages mentioned in this thread, I found this > manpage, the DETAILS AND APPLICATION CONSIDERATIONS section is worth > reading, IMHO: > > http://oskt.secure-endpoints.com/man/knc.1.pdf > > >> Now that I better understand the problem, something like the -q > >> [delay] option seems like the better solution. Even when talking to a > >> broken server, we don't necessarily want nc hanging around forever, > >> and maybe we don't know if the server is broken or not. So calling > >> shutdown after a delay will work in the greatest number of cases, > >> correct? > > > > What would be the behaviour without -q N in your proposal? > > > > -Otto > > Regards, > -- > J??r??mie Courr??ges-Anglas > GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
