From: Eric Wong <email@example.com>
To: Blake Williams <firstname.lastname@example.org>
Subject: Re: [PATCH] Add rack.after_reply functionality
Date: Wed, 9 Dec 2020 22:18:39 +0000 [thread overview]
Message-ID: <20201209221839.GA15862@dcvr> (raw)
Blake Williams <email@example.com> wrote:
> Totally understood. I looked at Puma, Thin, and Webrick and only Puma
> supports this functionality without a third-party gem. There is at least one
> third party gem adding this functionality to web servers that don’t support it,
> but it doesn’t look like it’s being maintained any longer.
Alright, I guess that third-party gem is no longer relevant.
> I briefly dove into the Puma source and it looks like rack.after_reply has
> been supported since 2011. It’s also still in use by Puma for their common
> logger middleware patch.
Thanks, pushed to https://yhbt.net/unicorn.git as
with Puma noted (see below) and extra `env' check added.
Anything else? Will wait a few days/week for others to chime in
and probably cut 5.8 in a week or so.
Btw, a sidenote about some strangeness in your mail replies:
I'm not sure why, but your "Reply-To" header is set to the
unbracketed Message-ID ("20201209094344.GA25593@dcvr") of the
message, which makes no sense...
I wonder if you or your mail client is confusing "Reply-To:"
with the "In-Reply-To:" header. They're completely different:
"Reply-To:" should be an email address you control (not a
Message-ID) if it differs from what's in the "From:" header.
In any case, your mail client already sets the "References:"
header correctly (probably w/o any interaction on your part),
and the "In-Reply-To:" header is not necessary (and it needs
angle brackets, anyways, since comments are allowed).
Author: Blake Williams <firstname.lastname@example.org>
Date: Tue Dec 8 16:47:16 2020 -0500
Add rack.after_reply functionality
This adds `rack.after_reply` functionality which allows rack middleware
to pass lambdas that will be executed after the client connection has
This was driven by a need to perform actions in a request that shouldn't
block the request from completing but also don't make sense as
There is prior art of this being supported found in a few gems, as well
as this functionality existing in other rack based servers (e.g. Puma).
[ew: check if `env' is set in ensure statement]
Acked-by: Eric Wong <email@example.com>
next prev parent reply other threads:[~2020-12-09 22:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 21:47 [PATCH] Add rack.after_reply functionality Blake Williams
2020-12-08 22:46 ` Eric Wong
2020-12-08 23:48 ` Blake Williams
2020-12-09 9:43 ` Eric Wong
2020-12-09 14:58 ` Blake Williams
2020-12-09 22:18 ` Eric Wong [this message]
2020-12-09 23:44 ` Blake Williams
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://yhbt.net/unicorn/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).