Date: Sun, 21 Jul 2013 19:02:26 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon Message-ID: <91998.1374458546@server1.tristatelogic.com> In-Reply-To: <CAJ-VmomyAi51VDzFh=QzbtT4EBsvsP4BocoE9-7Ca44Z1tcCGA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CAJ-VmomyAi51VDzFh=QzbtT4EBsvsP4BocoE9-7Ca44Z1tcCGA@mail.gmail.com> Adrian Chadd <adrian@freebsd.org> wrote: >Wait a second. What's going on under the hood? > >You _should_ be able to shutdown the write side of the socket and have >it not affect reading. It has been some time now since I filed my PR but I think that the bottom line is that you need to look at the code (of nc) to understand how it is reacting to EOF on stdin. My recollection is that it exits as soon as it sees that (i.e. EOF on its own stdin). My proposed patch corrects this unfortunate behavior. >It's a broken server if it does a read(), find >that the socket is returning EOF, and then not waiting for the write() >to fail before closing. The server(s) is/are not at fault in this instance. It is the *client*, i.e. nc, which is broken in its behavior. With respect to that, I *do* 100% agree with you that nc's current behavior is absolutely and unambiguously broken. What nc is currently doing is goofy and also provably counterproductive for most applications where one can envision nc being used, i.e. specifically in *non-interactive* scripting applications. In all such applications of nc it is essentially 100% likely that the input stream which will be given to nc will be coming from either (a) some disk file or else (b), more likely via a pipe from some other commands/scripts/programs. In all such cases, nc is likely to see the EOF on its stdin well before the remote server is finished sending down its reply, and thus, as has been demonstrated, nc will incorrectly truncate the server's reply. Note also that if you accept my premise, i.e. that nc is used, and that it will be used always (or virtually always) within non-interactive scenarios/contexts... leaving telnet for people who need a more inter- actively oriented tool... then there really is no need to accompany the change I have propsed with a new "-q" option, and instead the current behavior of nc can simply be changed from "exit-on-stdin-EOF" to "exit-on-remote-server-EOF", with no further or additional code changes. Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91998.1374458546>