Never mind...figured it out. I'm seeing a SIGPIPE now when the client disconnects. Sorry for the noise... On Sat, Feb 13, 2021 at 9:43 AM Paul Clements <paul.clements@us.sios.com> wrote:
I asked a similar question a few weeks ago, and am circling back because I am still in need of a solution. As it turns out, without a way to handle client/socket disconnect, I am having trouble finding a suitable working combination of Dancer2/PSGI Server. I've tried several, and while Twiggy does give an error (SIGPIPE) on client disconnect, my app is not AnyEvent- (or even thread-) based, so the forking servers (e.g., Starman) are a better fit (without rewriting substantial amounts of code).
At this point, I'm wondering if a fairly simple change to Dancer2 might be acceptable. It's a minimal change, but gives the Dancer2 app a way to know when a client disconnect has occurred in a "delayed" handler.
Specifically, it turns out that many/most servers return "undef" from their write routines once the socket is closed. So, the idea is to allow that information to pass back to the app:
diff --git a/lib/Dancer2/Core/DSL.pm b/lib/Dancer2/Core/DSL.pm index fd29ac74..9adb3e28 100644 --- a/lib/Dancer2/Core/DSL.pm +++ b/lib/Dancer2/Core/DSL.pm @@ -329,7 +329,7 @@ sub content {
eval { $Dancer2::Core::Route::WRITER->write(@_); - 1; + # use write's return code instead # 1; } or do { my $error = $@ || 'Zombie Error'; $Dancer2::Core::Route::ERROR_HANDLER
It doesn't seem like the constant 1 return code from "content" is something that anyone would be relying on, so changing it shouldn't hurt (?), but would provide a way to get the error information back to the app, e.g.:
my $client_ok = content $data; if (!defined($client_ok)) { # something's wrong!
Thanks, Paul