Re: Structured request headers deployment issues

Mike West <> Mon, 22 June 2020 05:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D9543A090B for <>; Sun, 21 Jun 2020 22:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id soqyPdbu6fA4 for <>; Sun, 21 Jun 2020 22:37:09 -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 DA8323A08F6 for <>; Sun, 21 Jun 2020 22:37:08 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jnF54-0006ia-6d for; Mon, 22 Jun 2020 05:33:18 +0000
Resent-Date: Mon, 22 Jun 2020 05:33:18 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnF50-0006h1-QD for; Mon, 22 Jun 2020 05:33:14 +0000
Received: from ([2a00:1450:4864:20::231]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jnF4y-0002bb-R7 for; Mon, 22 Jun 2020 05:33:14 +0000
Received: by with SMTP id z9so17747773ljh.13 for <>; Sun, 21 Jun 2020 22:33:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e9CShWdyI132aDayFIQ8GibNAqDR2PbLKXNHjwyfCI8=; b=mDUy7JsxcDh04DYpSy5AvxH7Een8eV2X2iow6ZerTOyaUJg043epYHeTdSIe4p5CpI PrNKCdkXJqjFnHuJ4543NcxfrFwxO7xQWFDjzUUpXCHGwmRvtcBks6X/s1Nq4cmhNOEP 4ZvLgW5BYSxMi0lUHbtPtpnSFaAKXIAZNqijp6WO1M2wPjUtUOjlPANHAM7j5yTrFkzd Hdw2bhsjzZOwj0HoK0EFzSnNHMaYezUcroZ1hMOBhvPwxjs1aZm4XHc860fzaUnBducr KvATlNkPBaSNQ3WPuDql+779cdszF185I+1jmPzSxbHOS0+REowxCO8drfd9RNX/PnO2 wuDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e9CShWdyI132aDayFIQ8GibNAqDR2PbLKXNHjwyfCI8=; b=QIL5bHt7soeOHpC6+edR+V1nibUU7TKqMk1Ns8e2cDx0JVp38LtGldjeLzA2MG4lXc oq/xUv02U7RHRQxJjFtdAr97U0SaiIcnS/DUh36i94oaVFGcsApOjkAD5Ud8gX2/EGig tCp187Fv1HFXam799I3LmCaBjgF2u6N6Jx0bPz8ImDuUeTjDXYbVL5Qqqfu4wAX5vs1z p4bsFZ5uFyuJvBjNioWi2/gQ8vWd6/JhKR1D6rSZwlH1JnqJ66jdbCZZZ5n5pzgDP0fM u9VyGG5XDDYLDkI047FOWDWdCynvMmSKLAfuIBWBE644JpNegPaS9WI/+w7EcZL3kl67 Pr8Q==
X-Gm-Message-State: AOAM532irWzZuruL696cBhG9wGPQUZ5fsauMM4U7p5u5tXztinbFys4S g0YQrbBC+hFzOG0Cp/3vE2vwiJ3exgrPhFrkFeBhezAicJkasQ==
X-Google-Smtp-Source: ABdhPJxCwWrTAUnTxuPKxrRtV5UlqLdJSzTw+32NOAfKRHspPHkqO+ss9AHpZ2N6XoDZGehG0yD46OvnrTwO5J3Es4Q=
X-Received: by 2002:a2e:974a:: with SMTP id f10mr7878505ljj.283.1592803980753; Sun, 21 Jun 2020 22:33:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mike West <>
Date: Mon, 22 Jun 2020 07:32:49 +0200
Message-ID: <>
To: Mark Nottingham <>
Cc: Yoav Weiss <>, " Group" <>, Tommy Pauly <>, Ilya Grigorik <>
Content-Type: multipart/alternative; boundary="00000000000078a63b05a8a59316"
Received-SPF: pass client-ip=2a00:1450:4864:20::231;;
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jnF4y-0002bb-R7 b1f30716a30bdf9c40d56e7957627e3b
Subject: Re: Structured request headers deployment issues
Archived-At: <>
X-Mailing-List: <> archive/latest/37808
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mon, Jun 22, 2020 at 5:19 AM Mark Nottingham <> wrote:

> > On 19 Jun 2020, at 5:03 pm, Mike West <> wrote:
> >> 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).
> >
> > The flip-side of this is that we break sites users rely upon. That's
> tough to do at scale. In this case in particular, I think I agree with the
> underlying assertion that we'd like this syntax to work, and it seems
> reasonable to me to roll it out to a small percentage of stable users. That
> said, if we end up breaking the internet for even a small percentage of
> users, it doesn't seem like a good idea to hold them hostage in the hopes
> of increasing pressure on WAF vendors.
> I don't think we disagree. The problem is that there is always going to be
> a small percentage that break, unless we severely limit the evolution of
> the Web (i.e., don't use new headers at all, especially given the data Yoav
> is bringing!), so the relevant question is *how much*.
> In other words, there's a theshold below which you're comfortable breaking
> a *few* sites, and those few sites presumably feel the pressure to change.
> Above that threshold, you're unwilling to cause too much damage, and the
> sites presumably feel comfortable in persisting their behaviour
> (acknowledging that there's some fuzziness on both sides).

I agree that we're not disagreeing. :)

> My expectation is that we'd roll this out to a small percentage of
> stable, see a spike in bug reports (especially from enterprise folks who
> are likely to have WAF deployments, unlikely to broadly deploy beta
> channels, and unlikely to choose to enable usage statistics or histograms),
> see a corresponding spike in error codes for top-level navigations, and
> roll it back.
> >
> > I think it might be reasonable to explore alternate spellings at the
> same time, perhaps with some A/B testing to evaluate how well each weaves
> its way through middleware.
> What's missing here are the ability to engage the WAF community, and time.
> Unlike Web sites, there's a relatively smaller number of WAF vendors out
> there, so it's not unreasonable to engage with them to bring the numbers
> down below the threshold. That will take time, especially since WAFs don't
> yet have auto-update capabilities on par with browsers, but I think it's
> worth doing.

For better or worse, it seems to me that this asymmetry in update
capability puts more onus on user agents to fit themselves to the world as
it exists, as they're likely to be able to move more quickly (or at all!).

> What I don't want to see is the Web become ossified on what a few WAFs
> happened to do in June 2020.

To this end, I wonder if some sort of GREASEd header would be reasonable
for user agents to start sending on some subset of requests. The user agent
client hints might end up accidentally serving as that header, but I don't
think Chromium's implementation even attempts to exercise all the bits and
pieces of

>> 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.
> >
> > I am interested!
> Great. I've heard from a few other folks too, so we'll try to figure out
> the appropriate venue for further discussion.
> Cheers,
> --
> Mark Nottingham