Re: Fwd: New Version Notification for draft-nottingham-bikeshed-length-00.txt

Willy Tarreau <w@1wt.eu> Wed, 18 March 2020 04:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
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 B26293A1033 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 Mar 2020 21:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISaH5b2b9Bjr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 17 Mar 2020 21:08:49 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B932C3A1036 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 17 Mar 2020 21:08:49 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jEPxG-0008W8-7C for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Mar 2020 04:05:18 +0000
Resent-Date: Wed, 18 Mar 2020 04:05:18 +0000
Resent-Message-Id: <E1jEPxG-0008W8-7C@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1jEPxE-0008VH-CV for ietf-http-wg@listhub.w3.org; Wed, 18 Mar 2020 04:05:16 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1jEPxC-0003Xi-Cw for ietf-http-wg@w3.org; Wed, 18 Mar 2020 04:05:16 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 02I44vtV012336; Wed, 18 Mar 2020 05:04:57 +0100
Date: Wed, 18 Mar 2020 05:04:57 +0100
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20200318040457.GA12317@1wt.eu>
References: <158449485958.32126.16514800548442242620@ietfa.amsl.com> <3DD75975-2CA3-4071-974C-922121689310@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3DD75975-2CA3-4071-974C-922121689310@mnot.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jEPxC-0003Xi-Cw 6ea1f327a05554a2b0431ec505099220
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Fwd: New Version Notification for draft-nottingham-bikeshed-length-00.txt
Archived-At: <https://www.w3.org/mid/20200318040457.GA12317@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37454
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Mark,

On Wed, Mar 18, 2020 at 12:29:24PM +1100, Mark Nottingham wrote:
> FYI, as discussed in <https://github.com/httpwg/http-core/issues/276>.
> 
> Prettier version at <https://mnot.github.io/I-D/bikeshed-length/>.

Interesting. I've also thought many times "too bad we don't have a distinct
header field for this one". I too think that something advisory may be
very useful, but I'm also seeing some misuse. Typically some recipients
might decide to allocate a large enough memory area to receive the
advertised contents, and this will be used to DoS some servers by sending
very large lengths (as we used to see with C-L in the past).

Despite this I still think that if we word it appropriately (i.e. "do not
trust it") and if we make sure it is never correlated to the effective
length, we could easily address potential issues and make it useful.

I think that it could be worded as suggesting that even the sender does
not necessarily precisely know the exact value to place there. For example
if a client needs to decompress a file before sending it, it could
arbitrarily advertise 10 times its compressed size. Similarly a client
uploading a log file could advertise the current size plus a small
margin, knowing that the file might continue to grow during the transfer.

If presented like this it should be clear that the recipient must not trust
it for anything but a progress bar or 413 and that could be very useful.

BTW I wouldn't say "it is not allowed to occur in trailer sections" since
it's not expected to have any particular meaning there, and adding a new
rule will only make its processing more complicated, I'd simply say that
it's pointless to place it there and that it may be ignored.

Willy