From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 03:06:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C09D324D for ; Mon, 22 Jul 2013 03:06:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A17C21F1A for ; Mon, 22 Jul 2013 03:06:23 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5E7F33B604 for ; Sun, 21 Jul 2013 20:06:20 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Sun, 21 Jul 2013 20:06:20 -0700 Message-ID: <94798.1374462380@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:06:23 -0000 In message Adrian Chadd wrote: > On 21 July 2013 19:02, Ronald F. Guilmette wrote: > >> 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. > >Gah, I was kinda hoping not to look at nc, and just work with someone >else to figure out the right solution. I'm being slack :) I did not know that was allowed on the freebsd-hackers list. :-) >> 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. > >OK. Let me re-read this. I _think_ the correct behaviour is: > >* if it's done a shutdown(fd, WR) - then it shouldn't error out on EOF >events on writes to the FD What? I don't understand what you just said. >* But it shouldn't get a read EOF on the socket until the remote side >signifies it. It isn't just that it "shouldn't". It most certainly DOES NOT receive an EOF from the remote server until such time as the remote server does in fact close down its side of the connection. >Is nc seeing EOF on reading form the server side prematurely? No. It is not. Prior to receiving the final portion of the response from the remote server and prior also to the remote server closing its end of the connection (i.e. ``sending an EOF'') the nc program see an EOF on its stdin channel and it decides, based on that alone, that it should exit immediately without waiting _either_ for further data coming down from the remote server _or_ for the actual and final EOF from the remote server. The result is that nc has a tendency to truncate the response data that is coming back from the remote server, only printing just the (incomplete) first part of it, rather than all of it, as it arguably should be doing. I hope that helps. Regards, rfg