Re: Middleware and post-request processing

[Eric Wong <normalperson@yhbt.net>]

ghazel <ghazel@gmail.com> wrote:
> 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.

I remember Aaron Patterson started thinking/blogging about it, at least.
search: "rack api awkward"

> 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.

I should note OobGC used to (really) be middleware, but I had to rewrite
it (as a Unicorn module) because Unicorn also needs to support
middleware that captures the block passed to body#each and reuses the
block in body#close.

> 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.

Any new post-response stage should give information about whether a
client is persistent or not (and maybe even if it started pipelining the
next request).

It would be great to have a standardized API that makes logging whether
a connection is keepalive/pipelined, but Rack doesn't get into that
right now.


As an author of Rack servers, I'll continue the my conservative personal
policy of not implementing new APIs unless:

1) it's added to the Rack spec, or
2) another widely-used server implements it (e.g. Thin
   with the async/deferred? stuff)

-- 
Eric Wong