Re: Generating a 421 status from a proxy

Mark Nottingham <> Tue, 28 April 2020 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2989D3A0FA1 for <>; Tue, 28 Apr 2020 01:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=WpDfAB+j; dkim=pass (2048-bit key) header.b=m7fzo24i
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7NY9hVlGp6Jr for <>; Tue, 28 Apr 2020 01:31:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 941B63A0FD2 for <>; Tue, 28 Apr 2020 01:31:32 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jTLak-0007ph-2s for; Tue, 28 Apr 2020 08:27:46 +0000
Resent-Date: Tue, 28 Apr 2020 08:27:46 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jTLaj-0007ov-Ag for; Tue, 28 Apr 2020 08:27:45 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jTLah-0007nQ-1U for; Tue, 28 Apr 2020 08:27:45 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id D2B0A47B; Tue, 28 Apr 2020 04:27:26 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 28 Apr 2020 04:27:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=k XTp+alxStOu8TGmZDNsT/Zmbm7IH3GlmXjXG2PG9fM=; b=WpDfAB+jhX7p8mV8a vkxCA7Pr4zRE1VgeFnyC3LUccnouA2p9ufjUqjDBtx5i6ep6tgQDEtFCkUMkj4bQ 9TLkrrxRcPdTJdc0Xr0VJryfSk+p7ezwNfPYrbzJtI9dPPfmWz0Wz0/qrOiL4Ll9 c6+nXW11XXg7UGLPOFyewLBw6f059jUsewC5Cf/LTayYCGAPMModdLlWEtjRHlrR mVTZXXjr2DIldLRxtt6P7RbHlUXHm7BAIpmwwJKJYkKM3br2tPslOslZUPz4qW1V yi0AMit7GJxyuBmXCfTDFt0c/JBQdIP925NeJTBjqwikV2kKegZPWsLbqMNQptRg M49TA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=kXTp+alxStOu8TGmZDNsT/Zmbm7IH3GlmXjXG2PG9 fM=; b=m7fzo24i9oSGroJ/nKp8b2QUryX+zpjy8IJZGqF70ceCkUYbuVvxqcxHv pM4GVnzOwuSo1P2uaiN9Fdqsvi9QLayOSidv3NFwZTbObv7esvvcZSFMJkdl47pZ wk58NYuXNqzCfX67kj/HC9oaXOQOpD/EORHf9Fu46iEDios+fiPhenGA13arGnVw Yd0anykOvPOVx1t6x3ytZV69C4Qv/habjbftY2bl67Y4pbq1OwZqlC/095QYXa9B xd10CBq2xwbWCEZsPI0Dyv6ODZCN+bM20NlLSl+wV2uEtZr5RbLGWZkFdDPl4Sfi KDbNt+aI0NYZVpRnXspmA174PD4XA==
X-ME-Sender: <xms:7einXv7wNiGsXX3tEOoxBSTM2kNHVN4o8StODKFRMkuR3CffBBKb4g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedugddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhephhhtthhpfihgrdhorhhgpdhmnhhothdrnhgvth enucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:7einXo8qVjvnmAeUpoZqdoM3E_8Eb-sS3W050ncw6llHfYvGpP4eIQ> <xmx:7einXrovwBu8nXFDVncD348Qoey_GHBe8fypzUCLPqMVu2c3FjjCKg> <xmx:7einXgpURCAK_jCqf4cL9DjdRBw7ew69C9k1BAP4hYI8-Y_K4ojc0A> <xmx:7uinXqr4X9N--jU80Lqs8cyedyh6SqSPFw54vBG_IQlaidUs6RB3cQ>
Received: from ( []) by (Postfix) with ESMTPA id 828723280059; Tue, 28 Apr 2020 04:27:24 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 28 Apr 2020 18:27:22 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: James Peach <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jTLah-0007nQ-1U e000c70a79b3ca56dbe7eb137d1a1748
Subject: Re: Generating a 421 status from a proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/37556
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi James,

You've got it right. "Reverse proxy" is just a colloquialism (because many of them started as "forward" proxy products).


> On 28 Apr 2020, at 12:59 pm, James Peach <> wrote:
>> On Apr 28, 2020, at 12:44 PM, James Peach <> wrote:
>> Hi all,
>> I have an reverse proxy Envoy configuration where each SNI server name is attached to exactly one virtual host routing table. If this configuration is deployed with a wildcard certificate however, browser clients will re-use the TLS connections for server name A to send requests for origin B, due to connection reuse, In this configuration, envoy generates a 404 because the configuration for servername A doesn’t have any routes for B.
>> I believe that in this situation, generating a 421 response should cause the client to not re-use the connection for a different (but wildcard-matching) hostname. However, the spec also says that a proxy must not generate a 421. I wasn't able to track down any rationale for why a proxy must not generate a 421; would it be considered inappropriate in this kind of configuration? Or is it OK, since from the client’s perspective, the reverse proxy is the origin?
>> The example use case for 421 status in section 9.1.1 is a TLS-terminating middlebox, which matches my scenario pretty closely. To my reading, this conflicts with the "MUST NOT be generated by proxies” requirement in 9.1.2. 
> To answer my own question (I think) ... the reverse proxy is a "gateway", not a “proxy”, so the MUST NOT doesn’t apply here.
> J

Mark Nottingham