From a6d50dc1098c01a1c3092a7f0f8aa154331600a3 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Wed, 3 Aug 2022 07:59:09 +0000 Subject: www: gzip_filter: gracefully handle socket ->write failures Socket ->write failures are expected and common for TCP traffic, especially if it's facing unreliable remote connections. So just bail out silently if our {gz} field was already clobbered during the small bit of recursion we hit on ->write failures from async responses. This ought to fix some GzipFilter::zflush errors (via $forward ->close from PublicInbox::HTTP) I've been noticing on deployments running -netd. I'm still unsure as to why I hadn't seen them before, but it might've only been ignorance on my part... Link: https://public-inbox.org/meta/20220802065436.GA13935@dcvr/ --- lib/PublicInbox/GzipFilter.pm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'lib/PublicInbox/GzipFilter.pm') diff --git a/lib/PublicInbox/GzipFilter.pm b/lib/PublicInbox/GzipFilter.pm index e37f1f76..c586d2f8 100644 --- a/lib/PublicInbox/GzipFilter.pm +++ b/lib/PublicInbox/GzipFilter.pm @@ -149,10 +149,11 @@ sub zflush ($;$) { my $zbuf = delete $self->{zbuf}; my $gz = delete $self->{gz}; my $err; - if (defined $_[1]) { + if (defined $_[1]) { # it's a bug iff $gz is undef w/ $_[1] $err = $gz->deflate($_[1], $zbuf); die "gzip->deflate: $err" if $err != Z_OK; } + $gz // return; # not a bug, recursing on DS->write failure $err = $gz->flush($zbuf); die "gzip->flush: $err" if $err != Z_OK; $zbuf; -- cgit v1.2.3-24-ge0c7