From 5f329e4d46422fc3cd8f1f2477b953e2e9ed8289 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Fri, 13 Nov 2009 18:42:58 -0800 Subject: revactor/tee_input: raise ClientDisconnect on EOFError Based on unicorn.git commit e4256da292f9626d7dfca60e08f65651a0a9139a raise Unicorn::ClientShutdown if client aborts in TeeInput Leaving the EOFError exception as-is bad because most applications/frameworks run an application-wide exception handler to pretty-print and/or log the exception with a huge backtrace. Since there's absolutely nothing we can do in the server-side app to deal with clients prematurely shutting down, having a backtrace does not make sense. Having a backtrace can even be harmful since it creates unnecessary noise for application engineers monitoring or tracking down real bugs. --- lib/rainbows/revactor/tee_input.rb | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'lib') diff --git a/lib/rainbows/revactor/tee_input.rb b/lib/rainbows/revactor/tee_input.rb index b34931f..fb7fa42 100644 --- a/lib/rainbows/revactor/tee_input.rb +++ b/lib/rainbows/revactor/tee_input.rb @@ -32,10 +32,21 @@ module Rainbows end end finalize_input + rescue EOFError + # in case client only did a premature shutdown(SHUT_WR) + # we do support clients that shutdown(SHUT_WR) after the + # _entire_ request has been sent, and those will not have + # raised EOFError on us. + socket.close if socket + raise Unicorn::ClientShutdown, "bytes_read=#{@tmp.size}", [] end def finalize_input while parser.trailers(req, buf).nil? + # Don't worry about raising ClientShutdown here on EOFError, tee() + # will catch EOFError when app is processing it, otherwise in + # initialize we never get any chance to enter the app so the + # EOFError will just get trapped by Unicorn and not the Rack app buf << socket.read end self.socket = nil -- cgit v1.2.3-24-ge0c7