On Tue, Mar 19, 2013 at 07:48:41PM +0100, Otto Moerbeek wrote:
> On Tue, Mar 19, 2013 at 02:35:49PM -0400, Ted Unangst wrote:
>
> > On Tue, Mar 19, 2013 at 17:39, Stuart Henderson wrote:
> > > On 2013/03/19 18:26, Otto Moerbeek wrote:
> > >> On Tue, Mar 19, 2013 at 04:00:46PM +0100, Martin Pelikan wrote:
> > >>
> > >> > > wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
> > >> >
> > >> > Of course you're right. I was so focused on finding the bug I didn't
> > >> > look above what the fd is :-(
> > >> >
> > >> > Are you okay with removing this particular shutdown(2) line?
> > >>
> > >> Yes, but it would even be better if there would be an option to get
> > >> the shutdown on EOF behaviour back.
> > >>
> > >> Some servers wait until they see the shutdown from the client to finish
> > >> their work.
> > >>
> > >> -Otto
> > >>
> > >
> > > OK?
> >
> > woah. Can somebody explain, using very small words, exactly what the
> > problem is?
> >
> > >From reading the ubuntu bug report, their problem comes from adding a
> > -q flag very similar to the proposed -N flag, and *that's* what broke.
> > Unmodified netcat does not have whatever bug they're talking about.
> >
> > Why are we adding a flag that the ubuntu bug report is requesting be
> > reverted?
> >
> > For that matter, if this is a real problem, why are we using -N and
> > not -q? This seems like a wholly gratuitous difference for no benefit.
>
> The testcase in the ubuntu bugreport is not really good.
>
> Try
>
> $ echo 129.128.5.194 | nc whois.ripe.net 43
>
> Our netcat does have a problem. It makes sense to default to the gnu
> netcat behaviour, which does not shutdown on EOF on stdin.
>
> -Otto
Maybe some more explanation is needed.
nc read from stdin, and current shut down its write side of the socket
when it sees EOF on stdin.
The shutdown is not a complety shutdown of the pipe between client and
server. But after it, the server will see an EOF on its reading end,
instead of blocking on read. The whois server interprets this as a
"connection is terminated" and completely stops sending data, even if
it has not fully sent the reply.
If the client does not do the shutdown, nc will receive all data
followed by EOF on the read side of the socket. After that it will
quit.
This is what gnu netcat also does: it only looks at the network side
to decide wether to quit or not.
Now there are cases where a shutdown is nice to have. Most simple
example is: enable echo service in inetd.conf. Talk to it using nc.
There is no real protocol, and it is nice to have a way to shutdown
the connection on EOF on stdin. If we completely remove the ability
to to a shutdown on EOF on stdin, you have no other option than to ^C
nc.
-Otto
