Control: tag -1 + pending Hi,
just run into this, too. gregor herrmann wrote: > Control: tag + confirmed bookworm sid Indeed, it still works on Debian 11 Bullseye, so it is clearly no change on the server side. (Which is reverse-proxied at Cloudflare and Cloudflare known to be quite easy on blocking specific user agents. And there seem to be User-Agent header related issues, too: https://rt.cpan.org/Public/Bug/Display.html?id=131931 — so that and the ancient "HTTP/1.0" were my first guesses for potential causes.) > A bit of debugging in the code shows that the "only" problem is > > 216 close $conn or die "Connection failed: $!\n"; > > in /usr/share/perl5/WWW/Dict/Leo/Org.pm. If I change the die() to a > warn() or comment out the line, everything works. Interesting, thanks! > I have no idea why "close $conn" fails, it might be related to > changes in OpenSSL3 and/or IO::Socket::SSL ($conn = new > IO::Socket::SSL(...)). -- $conn->close() fails as well without any > further information. I suspect OpenSSL3 as well because that was quite a bump in changes. Nevertheless, IO::Socket::SSL is inbetween, so I looked at its documentation. From the IO::Socket::SSL POD: IO::Socket::SSL tries to emulate the usual socket behavior as good as possible, but full emulation can not be done. Specifically a read on the SSL socket might also result in a write on the TCP socket or a write on the SSL socket might result in a read on the TCP socket. Also "accept" and close on the SSL socket will result in writing and reading data to the TCP socket too. Especially the hidden writes might result in a connection reset if the underlying TCP socket is already closed by the peer. Unless signal PIPE is explicitly handled by the application this will usually result in the application crashing. It is thus recommended to explicitly IGNORE signal PIPE so that the errors get propagated as EPIPE instead of causing a crash of the application. Tried that, but it didn't help. I also checked what close() returns. It is actually "undef". Also IO::Socket::SSL does not document any return value for close(). So the return code is actually not meant to mean anything. Additionally the POD also states on close(): The default behavior is thus to only send a close notify but not wait for the close notify of the peer. If this is required "SSL_fast_shutdown" need to be explicitly set to false. So it also does have nothing on which a success or failure could be determined. So IMHO we can and should just drop that "or die()". Will do and also add some more debug output to be easier able to debug such issues. Will also use that debug output to debug and possibly fix https://rt.cpan.org/Public/Bug/Display.html?id=131931 Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
