Re: GET / DELETE request bodies

Cory Benfield <cory@lukasa.co.uk> Fri, 06 March 2020 08:32 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 B8D563A0A15 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2020 00:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lukasa-co-uk.20150623.gappssmtp.com
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 K-0eGq2G25Wv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 6 Mar 2020 00:32:23 -0800 (PST)
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 91AEF3A0A14 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 6 Mar 2020 00:32:23 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jA8LW-0001Th-LX for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Mar 2020 08:28:39 +0000
Resent-Date: Fri, 06 Mar 2020 08:28:38 +0000
Resent-Message-Id: <E1jA8LW-0001Th-LX@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <cory@lukasa.co.uk>) id 1jA8LM-0001Sp-CJ for ietf-http-wg@listhub.w3.org; Fri, 06 Mar 2020 08:28:28 +0000
Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <cory@lukasa.co.uk>) id 1jA8LK-0004rp-DK for ietf-http-wg@w3.org; Fri, 06 Mar 2020 08:28:28 +0000
Received: by mail-lj1-x235.google.com with SMTP id a10so1253105ljp.11 for <ietf-http-wg@w3.org>; Fri, 06 Mar 2020 00:28:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A0JDBGYG9dUQBeH8AHc26lcP6QFk2SkSJ57LEGNP6kQ=; b=OYJwZDOIBeJGW/PFT+FkiQu6DURKlvuGnyEaPTCSl8ZbIRfeDGWiATTFRjp2hghiqs OamKSJLI+NbgIHhgXnS6iJYFbVj2dhduriZed3o8HyrfReuPrWMwqiaTAADrSKBj1DZK l5k/+7tAJD0E6DFaiwb9KoP8N0Uh1edN7HnLsR/pPoDMQGDeCnOs7bJn5dyRYPzbIOp6 rnNTlygDgalJ5VnA7Kg9Gut87I6eth9hlc2hEpeDxucBUIJF34/4mW49Huptk4FeWgTt De9r1bhAt67BjQZ22sa9SFoOmxO/A9yaQFnmTG8l4F5Q/th6RuxKKSJeLGxLdyZGTgSj 2WBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A0JDBGYG9dUQBeH8AHc26lcP6QFk2SkSJ57LEGNP6kQ=; b=pBsIf5BWRL8585PG0h9GhKYbrlhBxzSC76D0SXiX9f7dndIuPZmj0yZRk41ttcL8Ne MOWXqEYAltf97ApH6hPHm8O8fFKOLSxImTbqaULqRGopOMXhfxpqQN5zv1L+PPI2lEKb 0BzJXnG4sf2WsdJ7445ujV8cMvbbk0Aq4XvbdseZao1NXW8mh6OSJlbUDlM1jq0WkDDo YbpnqwXIMtPf+lbFs0+gNCM9RPUwzfWyeVDFP1rZGtW04odgYUs7B9b8Pbn/Xj1c+v2j T26fgQ48cfRMKTxSgPDUGcwNz4Bb4H0ycBiW8xeUpmx5YA+Ft5HhvFWqYKGjv4Wm2gJJ yDkA==
X-Gm-Message-State: ANhLgQ1dl4GV6W+d20VQxwEbudZb2M4932PrgQS+Hjh4I0a/FNCAlngw 3QtkeR8r/G8VWmwyqiwpSVP7h1ZghXjfTw183JiC5w==
X-Google-Smtp-Source: ADFU+vs5+fztOXI0UaI/3D7vz+xwTx/jC9Mix3m5lgNkOFQdI5w6vEeB3YG9ntlO7sV/Tt99QpjLJgCNAXGc80oAsbg=
X-Received: by 2002:a2e:8546:: with SMTP id u6mr1282816ljj.21.1583483293851; Fri, 06 Mar 2020 00:28:13 -0800 (PST)
MIME-Version: 1.0
References: <CAChr6SyZN4ceSeHkfQVnKRX7=RPnKjX_vAsL1mTHs18-MKRphQ@mail.gmail.com> <CAH_hAJEdM+NeVKAwEC+8uQf_0Dv-ArEtetuSoOW3wcV9WMeMZw@mail.gmail.com> <22665322-3F2B-4B2A-AE8F-91A53DE75B9E@gbiv.com> <CAH_hAJFF-o_iPzU-DxvjC2YafgTnep1xCW9pnsiRvuLncjWD0g@mail.gmail.com> <D757AFEF-E2F6-4CD4-BE1F-DB82986458E2@gbiv.com> <CAH_hAJH2s288J2gXux9mBmOP3GpKYb818=d6nbSkPmUKufpkbQ@mail.gmail.com> <000db291-2521-a828-9404-6102635f1e16@gmx.de>
In-Reply-To: <000db291-2521-a828-9404-6102635f1e16@gmx.de>
From: Cory Benfield <cory@lukasa.co.uk>
Date: Fri, 06 Mar 2020 08:28:02 +0000
Message-ID: <CAH_hAJHdYxMnv8UoW6Y=WgRwMouhcWHrgYiGbFePTOCVrQnFGw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Rob Sayre <sayrer@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::235; envelope-from=cory@lukasa.co.uk; helo=mail-lj1-x235.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: titan.w3.org 1jA8LK-0004rp-DK ea26f16db832f4ec0852888cf5b52cca
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GET / DELETE request bodies
Archived-At: <https://www.w3.org/mid/CAH_hAJHdYxMnv8UoW6Y=WgRwMouhcWHrgYiGbFePTOCVrQnFGw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37418
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>

On Tue, 25 Feb 2020 at 10:05, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> On 25.02.2020 10:13, Cory Benfield wrote:
> > Thanks Roy, this language seems like a reasonable compromise position.
> >
> > Of course, I expect it to be roundly ignored given how many HTTP
> > implementations currently use bodies on these requests today, but it's
> > nice to try to define the correct thing even if it isn't widely done.
>  > ...
>
> (devil's advocate) If they use request bodies here, doesn't that mean
> interop is quite good? Again, what problem are we solving by forbidding
> them?
>
> Best regards, Julian


I think this is a perfectly valid question. It was not clear to me
that there was an outstanding problem with supplying request bodies on
these requests, which is why my original response said "eh an
arbitrary endpoint won't understand them but if you control all the
endpoints then you can just do what you want". This is the
currently-used model for bodies in these requests.

On the other hand, I think Roy's argument (that in general bodies on
these requests are going to be ignored) is not unreasonable either.
After all, if you control all the endpoints you can just diverge from
the HTTP RFCs in any way you wish and nothing bad will happen. The
HTTP RFCs are only relevant where you care about what arbitrary other
protocol participants will do in the face of your message. I still
wish the new language were even clearer, and said something closer to
what Roy originally said in this thread, but I understand why we'd add
this language to the spec.