From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id C264D1F4B4; Wed, 9 Dec 2020 09:43:44 +0000 (UTC) Date: Wed, 9 Dec 2020 09:43:44 +0000 From: Eric Wong To: Blake Williams Cc: unicorn-public@yhbt.net Subject: Re: [PATCH] Add rack.after_reply functionality Message-ID: <20201209094344.GA25593@dcvr> References: <9873E53C-04D3-4759-9678-CA17DBAEF7B7@blakewilliams.me> <20201208224631.GA13148@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: Blake Williams wrote: > > > In the past, I've used response_body.close in middleware for > > similar things, and nowadays Rack::BodyProxy exists in rack, too. > > > > So I'm a little skeptical if this is actually needed, but it's > > probably too late to do anything about: > > The first approach we took uses Rack::Events, which I believe is using > Rack::BodyProxy under the hood. We ran into an issue where all but > the last line of the response is written and the connection isn’t > actually closed yet when the callbacks are called. OK. Keep in mind this can be server-dependent since unicorn can't support persistent connections while (most?) other servers do (and they may disable TCP_CORK or Nagle, etc). > > Citation(s) needed. Also, are there any proposal(s) to get this > > into the Rack specification? > > Not that I’m aware of. But I agree that it and early_hints could both be > good additions to the spec. By "Citation(s) needed", can you list some other (preferably well-known) Rack servers which also implement this feature? We wouldn't want current unicorn users thinking we're adopting random new things which nobody else supports :> Thanks.