From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 21 09:49:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDAC38E1 for ; Sun, 21 Jul 2013 09:49:46 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 65416F10 for ; Sun, 21 Jul 2013 09:49:46 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so1762926wiw.2 for ; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F3WNe18gIgcoNihh+nLFzNoXFhsjKQ5ePkm7ao9Jr2M=; b=B40XSRMN2dJHDJngqGrhkx7CIyBv17pXGebuBIJ3wYPyFERN7UA0VAM3EgM13ttqVq 6Esqe2OHBezIaAHDF6QLsb63zLePGmOXNsSsKrvpqi7TGcuD4MmZVM/WMDKO05qICUa3 xn4HrXG/2QlmKFSfyrJzjYrbnkBNOGcqMu7WJ/8XD3uLIdq5Gk2CIJkTaeE7vqyy9/dd yB8y1CkHz92u7Z+/A4jBrOHindgL59Xi0OpFj+WhJZ1tO+9Uxn4w8RScPltuaORME9X9 rzGiryCk7RkRhwgfGv7jhIHAUmyobAPB3Fvd+N8ZUnrmUGM4s4Es5V6TXAFbDGoEkRLN KjDA== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr16393341wjc.63.1374400184899; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) In-Reply-To: <24574.1374375946@server1.tristatelogic.com> References: <24574.1374375946@server1.tristatelogic.com> Date: Sun, 21 Jul 2013 11:49:44 +0200 Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers 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: Sun, 21 Jul 2013 09:49:46 -0000 On Sun, Jul 21, 2013 at 5:05 AM, Ronald F. Guilmette wrote: > > In message Z1A3PgBtChAEhMbqB5fwPx-7emGbTSJ7AyMPA@mail.gmail.com> > =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= > wrote: > > >It seems to work for me: > > Good. > > Just to make sure that we are clear, you are simply confirming what my > bug report (bin/176713) said, i.e. that _without_ my fix, nc can > prematurely > truncate the output from some servers, whereas _with_ my fix this bad > behaviour on the part of nc is cured... Is that correct? > Yes, that is what I tested. Behavior before (truncated output) and after (correct output) applying the patch. If this is going to be the final version of the patch, i.e. if it is going to include the -q flag, then the patch needs to be extended to reflect that in nc(1) man page. > > If so, thank you for confirming that my proposed fix produces the > desired result. > > I feel compelled to say again that in actual point of fact, the way that > I personally would prefer to see this problem resolved would *not* be to > add a new option for the nc program. Rather, I think that it would > actually be best simply to delete from the nc source code the one single > line that is causing nc to stop its operation as soon as it receives > an EOF from its stdin channel. If that line is simply deleted, then > nc will instead wait until it receives an EOF from the remote server > that it is talking to, and quite obviously, this change causes nc to > produce output which is arguably more correct and which is certainly > more useful that the prematurely truncated results that nc sometimes > produces at present. > > >> P.P.S. I have just realized that yet one more critical enhancement for > >> nc is called for, and I will be filing a separate and additional PR for > >> that soon. I hope that someone will be able to take a look at that as > >> soon as it is filed. > > > >Just out of curiosity. What is it about? > > Well, as it turns out, the additional "fix" that I had believed that I > was going to propose for nc was not that critical after all... at least > not for my current and immediate application(s). However it might still > have some value in some cases anyway, so I will describe what I had in > mind. > > Quite simply, I believe that it would be Good if the nc program had a > new and additional option which, when used, would cause nc to refrain > from sending any data _to_ the remote server until such time as it had > received one entire line _from_ the remote server. > > Such an option could be useful when using nc to communicate with remote > servers running certain protocols. For example, the rules of the SMTP > protocol... just to name one... require that a client wait until the > server has sent out an initial greeting banner before the client sends > anything to the server. Some SMTP servers are lenient about enforcing > this protocol rule, so in practice it may often not be necessary to wait > for the greeting banner before sending SMTP commands from the client to > the server. However there may perhaps be other instances where waiting > actually is required, and thus I believe that an option to produce that > kind of behavior might be a useful addition to the nc command. > > > Regards, > rfg >