From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org Mon Jan 30 10:36:39 2023 Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0323EC19E10D for ; Mon, 30 Jan 2023 10:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdnuI-wsjDhy for ; Mon, 30 Jan 2023 10:36:34 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10699C17EE09 for ; Mon, 30 Jan 2023 10:36:33 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pMYyo-004YMU-FE for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Jan 2023 18:34:10 +0000 Resent-Date: Mon, 30 Jan 2023 18:34:10 +0000 Resent-Message-Id: Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1pMYyn-004YL5-Cn for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2023 18:34:09 +0000 Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pMTXR-003Yfp-0Q for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2023 12:45:33 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pMTXP-00HYRK-Ko for ietf-http-wg@w3.org; Mon, 30 Jan 2023 12:45:32 +0000 Received: by mail-wm1-x329.google.com with SMTP id hn2-20020a05600ca38200b003dc5cb96d46so965973wmb.4 for ; Mon, 30 Jan 2023 04:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=vP1yVHk7Dj91bHxKUnAcd+/HAxlm2J0FkzWnqdBcxcY=; b=PTRUoWiG8Pnn6pT/tCwmr0bI2FD3MPYz4akJ3PYbT58gKox6UQ6z+YNOwEGGxA3vOJ Kjb1e8yTxA6CQA5vBlc0hzhQUD9ZKLCuYKbknCIY7B2W7xvCcOuQeXdG8l8rHaRsKqQM EdVpp65qNxEfbqFIQL8AMIrBYxGVynp2NiVleav6tIc0Hkgin4whHwyfM+GJDTBP+vPa 4P1XTqNa1M13ncp4fjCeCtq2ugdyPl7sfF1kSkaUMNFQJeeS2qQ0ggA006mu8us4KRdR xHmVYSBwY6djqdv16Q1E9eNkRRSQVPEanoWVZkDAyjBCQIeAXv89cAX+TABBh5wlCvRW b2YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vP1yVHk7Dj91bHxKUnAcd+/HAxlm2J0FkzWnqdBcxcY=; b=x8JgD+5UZN+QIY+bcuMeLd/NEO/g0w6hjtQEsWCmRM5D/l0ul3FTZaW2nDf0xi4j+n 5Pywj/h4l1a0skC0+C9O8o8+cY7Ou8GT5qFer/U57Tmts67jpxF+iqa7FJM5Qtt0zNvj khmUFNyOWrHJdwAEZdbj8xBvTuHBvNqvuhNJ6U4TUBrn4jdHV9eG1Gvy0kxwLuf1fmpj /GYkoOBQlf82gI5H24rtCIjeei3KKos7FaLelX5HHQpp+d9c9UHwUfy6THu1b6ZbnfPe I2AvQ4qLT1gz4I0rTn7N8h8enx0tGWXsPdEKO/UERrpbedq9KglctuYcJqYTUGJ27ZBp 6RDw== X-Gm-Message-State: AFqh2krmjFwf0oddfp9ht67NKOzbRDPQpvmLQB+eppujONyY8G2rqrSC pFxee/exMYhzTK92BMu+rbcY11zhbGSgoTCYvSBc612x X-Google-Smtp-Source: AMrXdXuol2Y172m5rcxKeuBOMWHTafRqfsdQqvbnjoWWdtKMoz0yeBAMuXB2oN9QqFDes8SYnJvByhO9kZ7xO0DbMuo= X-Received: by 2002:a05:600c:468f:b0:3db:eb0:706 with SMTP id p15-20020a05600c468f00b003db0eb00706mr1829762wmo.140.1675082719212; Mon, 30 Jan 2023 04:45:19 -0800 (PST) MIME-Version: 1.0 From: Nicolas Grekas Date: Mon, 30 Jan 2023 13:45:08 +0100 Message-ID: To: ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="00000000000072b9f305f37a96cc" Received-SPF: pass client-ip=2a00:1450:4864:20::329; envelope-from=nicolas.grekas@gmail.com; helo=mail-wm1-x329.google.com X-W3C-Hub-DKIM-Status: validation passed: (address=nicolas.grekas@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-4.1 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: mimas.w3.org 1pMTXP-00HYRK-Ko 012e914adc12e0831322aaee2e1a7c99 X-caa-id: 61c62567ef X-Original-To: ietf-http-wg@w3.org Subject: Idea for a new header to aggregate Vary headers' values Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/40718 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --00000000000072b9f305f37a96cc Content-Type: text/plain; charset="UTF-8" Hi all, I'm new to this mailing list and I don't know if I'm following the correct process. Please let me know if I should do things differently. Last September I met Darrel Miller at a conference and we chatted about the Vary header and its shortcomings. One of them is that the variety of values to vary-by can become huge. A simple "Vary: User-Agent" can yield a huge amount of cached resources. I've friends who solve this by doing a preflight request to some header-normalizer service they have in their stack: a request comes in, Varnish goes to that service, the User-Agent comes back with some normalized values, and then varnish can hit its cache storage with a much better cardinality. This is no simple setup and I'm wondering if a response header, possibly combined with 103 Early Hints couldn't make this much cheaper. The response header I'm proposing would contain the normalized value of every header to vary-by. I don't know how to encode that exactly. It could be e.g.: "Vary-Values: User-Agent: firefox, Accept-Encoding: identity, etc." We could also imagine a header to provide the normalized URL back, Vary-Url: http://the-normalized-url. (We could imagine that "Vary-Values" completely replaces "Vary" when both are found - but I've not thought much about this aspect.) These normalized values could be useful for reverse-proxies, to optimize their storage requirements + their hit/miss ratio. 103 Early Hints could also be used by reverse-proxies to abort a request to the backend app when that app sends a Vary-Values. Does it make sense? Has this been considered before? Please let me know if it's not clear enough of course. Regards, Nicolas --00000000000072b9f305f37a96cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm new to this = mailing list and I don't know if I'm following the correct process.= Please let me know if I should do things differently.

=
Last September I met Darrel Miller at a conference and we chatted abou= t the Vary header and its shortcomings. One of them is that the variety of = values to vary-by can become huge. A simple "Vary: User-Agent" ca= n yield a huge amount of cached resources.

I'v= e friends who solve this by doing a preflight request to some header-normal= izer service they have in their stack: a request comes in, Varnish goes to = that service, the User-Agent comes back with some normalized values, and th= en varnish can hit its cache storage with a much better cardinality.
<= div>
This is no simple setup and I'm wondering if a respo= nse header, possibly combined with 103 Early Hints couldn't make this m= uch cheaper.

The response header I'm proposing= would contain the normalized value of every header to vary-by. I don't= know how to encode that exactly. It could be e.g.: "Vary-Values: User= -Agent: firefox, Accept-Encoding: identity, etc."
We could a= lso imagine a header to provide the normalized URL back, Vary-Url: http://the-normalized-url.
(We= could imagine that "Vary-Values" completely replaces "Vary&= quot; when both are found - but I've not thought much about this aspect= ..)

These normalized values could be useful for= reverse-proxies, to optimize their storage requirements + their hit/miss r= atio.

103 Early Hints could also be used by rever= se-proxies to abort a request to the backend app when that app sends a Vary= -Values.

Does it make sense? Has this been conside= red before?
Please let me know if it's not clear enough of co= urse.

Regards,
Nicolas
--00000000000072b9f305f37a96cc--