WS 1006: Report OS error?

[FGasper]

Hi.

I have a WS client that’s reporting 1006 as its failure code. I strace’d and saw that it’s because the socket is getting ECONNRESET, but that’s not being reported as the reason for the 1006 error code.

Is there any interface that Mojo exposes that would tell me why a WS 1006 status happened? I could read $!, but that’s assuming that no other system call happened between whatever failure and the Perl code … which, I don’t know how safe that is.

Thank you!

(P.S.: Does anyone know a reason why both ends of a TCP connection would report ECONNRESET?)

[christopherraa]

For what it is worth: we keep seeing this. Every time we've done any extensive debugging it has been misbehaving "security" products on the clients end that just drops the traffic both ways. Someone else would have to answer if Mojolicious could detect this, but I suspect the answer is no.

[FGasper]

we keep seeing this

The double-sided ECONNRESET? Good to know!

Mojo can’t detect the double-reset, but it could at least somehow expose the ECONNRESET that its own I/O operation gets. Right now all I’m seeing is a 1006.

[kraih]

Suggestions for improvements would be very welcome.

[FGasper]

@kraih

mojo/lib/Mojo/IOLoop/Stream.pm

Lines 104 to 117 in 103b221

	sub _read {
	my $self = shift;
	if (defined(my $read = $self->{handle}->sysread(my $buffer, 131072, 0))) {
	$self->{read} += $read;
	return $read == 0 ? $self->close : $self->emit(read => $buffer)->_again;
	}
	# Retry
	return undef if $! == EAGAIN || $! == EINTR || $! == EWOULDBLOCK;
	# Closed (maybe real error)
	$! == ECONNRESET ? $self->close : $self->emit(error => $!)->close;
	}

^^ It actually looks like ECONNRESET is purposely “thrown away” … maybe just allow ECONNRESET to go out in an error event the same as other such errors?

[FGasper]

Looks like this behaviour of ignoring ECONNRESET dates from pre-1.0: a21fe0a

It makes sense for a server, but for a client doesn’t it make more sense to report abnormal connection termination than to ignore it?