Re: Structured request headers deployment issues

Mark Nottingham <> Fri, 19 June 2020 05:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86D803A0E3F for <>; Thu, 18 Jun 2020 22:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 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.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=dx9AhABJ; dkim=pass (2048-bit key) header.b=AP97+YYQ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rStPfdcwKMRQ for <>; Thu, 18 Jun 2020 22:16:26 -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 923CF3A0E33 for <>; Thu, 18 Jun 2020 22:16:26 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jm9LQ-00063Z-8Q for; Fri, 19 Jun 2020 05:13:40 +0000
Resent-Date: Fri, 19 Jun 2020 05:13:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jm9LM-00062h-Nx for; Fri, 19 Jun 2020 05:13:36 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jm9LK-0007fs-OU for; Fri, 19 Jun 2020 05:13:36 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id BE4895C014F; Fri, 19 Jun 2020 01:13:19 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Fri, 19 Jun 2020 01:13:19 -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=fm3; bh=j qvlvCO9gmVGQHhA+QTH7HxdQlPuR4suODLcXmX9CD0=; b=dx9AhABJDePMKz+// r4s7SuMbOByUXscPRnF15TO2tABhfQa2tSeNiaRNnBJNRJr4o0t5IGJP8KUeJXM+ NF+e2eb4bHPzgW244/cj/a5xarJLIUgibVqM24zMg0fCNPsf7ehxirG7LhThxVC7 7Fj2ALFrBnGBOcwjUIPWDH+lZPuKf2JPbPBlUU70skVzb2iGmc93BwMgTQF+d7Im xFbIiLI1UeCFUOwW7Crk53VtJvJI1KwjppYcAjlmuR4zO6S1kZfWRKg4neghEP6o Cl5hrpq8vSovfAD6Jv9TKeXLkTZ7YJvA9HJnPAAgTOWnIFDlteBJZth32LJNlFbF VD4cg==
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=fm3; bh=jqvlvCO9gmVGQHhA+QTH7HxdQlPuR4suODLcXmX9C D0=; b=AP97+YYQZ1Qi7TmzW9vAmKXW0tGCX/CD+Mo9+5DCkFHcl6rnuA7fI3jw/ c43GHmi5QA5tDs96Ksnj7PwtWT0y8o4hwOfVMJdQdJQqGtrTukrHU/FGOI1IKysQ hbUBTCFilwAoQA9pYJyb6wFWch5qab/3qW3jtMgieKH918vKpCupA1o+WAsLoq3I biGT7kIMgeFBhOLbwgary75zkpximsFZDaKP4v3V50NQEYd0MGm8AjCydztCyeGQ oXa2cswLwziVWrtPGSCyLUblHfeK8ePYIIRr+3JS1hkpUDZNqj6xK9vht1hEM743 NEs7l5u0MOTJCYw66GUzIFEbvQ1EA==
X-ME-Sender: <xms:bknsXqRiv3CxMAdcdU4PHKJmt_HvTrOu59jNdOLKJQjqtNp19yXvnw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejhedgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdludefmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhh tddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhoth drnhgvtheqnecuggftrfgrthhtvghrnhepleffvdeuveffffekgefgffeugeehleekkeet jeelhfelkeevkeduieeivedvtefgnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpmh hnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvg ht
X-ME-Proxy: <xmx:bknsXvxzQmNyLZHES0JdSxCNr9javlqQ3rwY1Jz4TYBS5NF2Hw2xBg> <xmx:bknsXn0iMGPrXnGQsIyGpDPKFIpnNDfqlB15CyIuut-o-kJg8kPa-g> <xmx:bknsXmBpmvDJVyo0_ZlrQHvzezjDXQkshkKEdEUNNVtegOqgZM5YPQ> <xmx:b0nsXjeZltNRzs7AXdvfn0VJ1QYxfN7a3XXSd5UF4XRmhK4LmaQyTg>
Received: from ( []) by (Postfix) with ESMTPA id E48F4328005D; Fri, 19 Jun 2020 01:13:16 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Fri, 19 Jun 2020 15:13:13 +1000
Cc: " Group" <>, Tommy Pauly <>, Ilya Grigorik <>, Mike West <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Yoav Weiss <>
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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: 1jm9LK-0007fs-OU 7618bfb1a58457bd57f0320ca1fc1d8a
Subject: Re: Structured request headers deployment issues
Archived-At: <>
X-Mailing-List: <> archive/latest/37795
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey Yoav,

> On 16 Jun 2020, at 8:15 am, Yoav Weiss <> wrote:
> Hey all,
> Chromium M84 (which Chrome equivalent is now in Beta) has User-Agent Client Hints enabled by default, which is using Structured Headers.
> As a result of that, we found multiple sites which seem to have a somewhat allergic reaction to the presence of certain characters (that are part of the SH format) in request values. 
> While each site in question is different (in what appears to be coming from different stacks), we've seen sites that reject requests with quotes, question marks or equals signs in them.
> It's still early, so it's hard to know how widespread the issue is, but we seem to be adding sites to the list at a faster pace than the pace of removing fixed ones from it.
> So, I wanted to give this group a heads-up on that front, and maybe get folks' opinions regarding possible things we could do on that front, other than outreach and waiting for said sites to fix themselves.

AIUI these aren't new; e.g., IIRC quite a few months ago Chrome encountered several Austrian sites that had this problem, traced back to a local(?) WAF vendor there. I believe that's been corrected since, after reaching out to them.

Personally, I think that outreach and waiting is the right approach; if browsers consistently send these headers, they'll adapt, and the numbers are still relatively small -- or at least small enough that it's not likely the numbers will be reduced if the syntax is changed (due to _other_ WAFs' opinions about what a "good" request is).

Also, if we get these headers through, it seems like it would give us good protection (of a sort) for future Structured request headers.

Related, we're also seeing more examples WAFs limiting how we can evolve the protocol (e.g., <>). There's been a bit of background chatter about writing something about this and creating better communication with that community; I'm not sure what that will look like yet, but if anyone has ideas or is interested, please say so.


Mark Nottingham