From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.70.129 with SMTP id d1cs61355qcj; Fri, 3 Jun 2011 16:38:32 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCKGMsZCuHxD14KXvBBoEx6d2RA@googlegroups.com designates 10.146.175.40 as permitted sender) client-ip=10.146.175.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCKGMsZCuHxD14KXvBBoEx6d2RA@googlegroups.com designates 10.146.175.40 as permitted sender) smtp.mail=rack-devel+bncCKGMsZCuHxD14KXvBBoEx6d2RA@googlegroups.com; dkim=pass header.i=rack-devel+bncCKGMsZCuHxD14KXvBBoEx6d2RA@googlegroups.com Received: from mr.google.com ([10.146.175.40]) by 10.146.175.40 with SMTP id x40mr132294yae.3.1307144311288 (num_hops = 1); Fri, 03 Jun 2011 16:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:x-beenthere:mime-version:date:user-agent :x-http-useragent:message-id:subject:from:to:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; bh=3EDS6reAr3kls8t/bxLLt8QNZiY4E6TWBQCQZTLqCdQ=; b=sn5Jjd6mIX/b6BXmiQNLmZQvc7pZ+/VoPqH+dNOgxYZjmDNVTtXE5bHevmBcdBF9Bq BocJtcJOgGanGF4eydti6e0veGPm4M1s+sw+h7nnhRylO6mCfgi2al/uX6Ex8pg87iQf Eb7i/+FWubSWeNBekNyeuQM1qtrqBAeqUfq/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:mime-version:date:user-agent:x-http-useragent :message-id:subject:from:to:x-original-sender:reply-to:precedence :mailing-list:list-id:x-google-group-id:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe:content-type; b=C5BsjYfjJeQNIfhn41/k9apT1zRc4GhtPi0GeTtBecHM1dWAc1vjxunsSHFU9YvAmt CD2JS89tMqT4H2bwL6jf3yMR9fq144sD/pZtJz2zRINc3QcynNT0HIFZIQ68eeVXlCP+ HNYzkkclePL2bqBl2dwHIW0UCj9gnOzGqfYVM= Received: by 10.146.175.40 with SMTP id x40mr37273yae.3.1307144309052; Fri, 03 Jun 2011 16:38:29 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.150.228.9 with SMTP id a9ls2278113ybh.6.gmail; Fri, 03 Jun 2011 16:38:28 -0700 (PDT) Received: by 10.236.153.132 with SMTP id f4mr1341183yhk.92.1307144308196; Fri, 03 Jun 2011 16:38:28 -0700 (PDT) Received: by 10.151.1.41 with SMTP id d41msybi; Fri, 3 Jun 2011 16:23:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.199 with SMTP id t7mr185410pbi.18.1307143390438; Fri, 03 Jun 2011 16:23:10 -0700 (PDT) Received: by f31g2000pri.googlegroups.com with HTTP; Fri, 3 Jun 2011 16:23:10 -0700 (PDT) Date: Fri, 3 Jun 2011 16:23:10 -0700 (PDT) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.68 Safari/534.30,gzip(gfe) Message-ID: <2cac8438-1819-4887-bce9-9a99578539db@f31g2000pri.googlegroups.com> Subject: Middleware and post-request processing From: ghazel To: Rack Development X-Original-Sender: ghazel@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=ISO-8859-1 It seems to me that Rack is in need of a new post-response stage of processing. This stage would occur after the response is fully written and the client is unblocked, and before the next request is processed. Similar to what OobGC ( http://bogomips.org/unicorn.git/tree/lib/unicorn/oob_gc.rb#n59 ) accomplishes, it is sometimes useful to perform additional operations after the response is written without blocking the client. For example, the Oink middleware logs statistics about the request, but blocks the response since it has no ability not to: ( https://github.com/noahd1/oink/blob/4158d71bc9150f011072b2c6eefe73c720a78d46/lib/oink/middleware.rb#L16 ). This processing takes time, and needlessly delays the response. This proposal would entail something like a single function which is called on each middleware after the response is written to the client and the socket is closed (depending on the server implementation). For servers which have no ability to not block the client or delay further requests the function should still be called, and the impact would be similar to the behavior today. Thoughts?