Terminates after sigpipe if client close connection [rt.cpan.org #85904]

Migrated from rt.cpan.org#85904 (status was 'new')

Requestors:

• victor@vsespb.ru

From victor@vsespb.ru on 2013-06-05 19:36:40
:

This behaviour is observed at least last ~5 years, so I am not sure maybe it's a feature.

I can submit PoC if required.

From victor@vsespb.ru on 2014-06-10 19:11:29
:

On Wed Jun 05 23:36:40 2013, vsespb wrote:
> This behaviour is observed at least last ~5 years, so I am not sure
> maybe it's a feature.
> 
> I can submit PoC if required.

====

use strict;
use warnings;
use HTTP::Daemon;

my $PORT = 55001;

if (fork()) { # parent
	#$SIG{PIPE}=sub{die "HEY\n";};
	my $d = HTTP::Daemon->new(Timeout => 20, LocalAddr => '127.0.0.1', LocalPort => $PORT);
	while (my $c = $d->accept) {
		my $r = $c->get_request;
		my $body = "x" x 100_000;
		my $resp = HTTP::Response->new(200, 'OK', [], $body);
		$c->send_response($resp);
		print STDERR "sent\n";
		$c = undef;  # close connection
	}
	print "DONE\n";
	wait;
} else { # child
	my $sock = IO::Socket::INET->new(PeerAddr => '127.0.0.1', PeerPort => $PORT, Proto    => 'tcp');
	print $sock "GET /\n\n";
	close $sock;
}


====

perl daemonpoc.pl || echo $?
will print 141. this means SIGPIPE (SIGPIPE number is 13 + 128 = 141).

also if you uncomment 
#$SIG{PIPE}=sub{die "HEY\n";};
it will print "HEY"

I think it something that should be at least documented.
people who use high level API like $c->send_response($resp); have insperation that they don't do low level things like writings to the sockets, so they are not expect they need to handle SIGPIPE.

Start with the daemonpoc.pl example in the issue and reproduce the SIGPIPE termination using HTTP::Daemon->send_response. Read the HTTP::Daemon documentation and the send_response path to determine whether the behavior should be documented or changed. Done means the expected client-close behavior and handling guidance are clearly established.