Re: GET / DELETE request bodies

"Roy T. Fielding" <fielding@gbiv.com> Mon, 24 February 2020 18:17 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 2C7913A1088 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 24 Feb 2020 10:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
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.25, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=gbiv.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 y5PNBKOPEBwS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 24 Feb 2020 10:17:16 -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 46FEB3A1085 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 24 Feb 2020 10:17:16 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1j6IEs-0001hw-Lz for ietf-http-wg-dist@listhub.w3.org; Mon, 24 Feb 2020 18:13:54 +0000
Resent-Date: Mon, 24 Feb 2020 18:13:54 +0000
Resent-Message-Id: <E1j6IEs-0001hw-Lz@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 <fielding@gbiv.com>) id 1j6IEn-0001h6-GW for ietf-http-wg@listhub.w3.org; Mon, 24 Feb 2020 18:13:49 +0000
Received: from fossa.birch.relay.mailchannels.net ([23.83.209.62]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fielding@gbiv.com>) id 1j6IEl-0003qj-Iy for ietf-http-wg@w3.org; Mon, 24 Feb 2020 18:13:49 +0000
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 82C21341220; Mon, 24 Feb 2020 18:13:34 +0000 (UTC)
Received: from pdx1-sub0-mail-a59.g.dreamhost.com (100-96-42-17.trex.outbound.svc.cluster.local [100.96.42.17]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D77643413C9; Mon, 24 Feb 2020 18:13:33 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a59.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Mon, 24 Feb 2020 18:13:34 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Madly-Industry: 5e967262420e71db_1582568014312_1418743937
X-MC-Loop-Signature: 1582568014312:4098356470
X-MC-Ingress-Time: 1582568014311
Received: from pdx1-sub0-mail-a59.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a59.g.dreamhost.com (Postfix) with ESMTP id 5F2077F148; Mon, 24 Feb 2020 10:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=gbiv.com; bh=JeJQJl0YOr6YNIuUGdz81MbDBT8=; b= jivrq34wIPwuEXTi2dbaZNVLKt5Z8bN4unx5tgbSsjIQgg+hzPlPnEcQDSWXZlSE KAbZvnvUDIGP902Z9STrJ6iic4mjdnwWGlkFQXTvAdIfM4EezUlZSfHPJWjDvOVX HfXNvGy97SoYlZ+DQbfJkToHx3qZI0TCQJO0zZgC45o=
Received: from [192.168.1.4] (ip68-228-81-25.oc.oc.cox.net [68.228.81.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a59.g.dreamhost.com (Postfix) with ESMTPSA id 04AAA7F17A; Mon, 24 Feb 2020 10:13:29 -0800 (PST)
X-DH-BACKEND: pdx1-sub0-mail-a59
From: "Roy T. Fielding" <fielding@gbiv.com>
Message-Id: <9C9C0E9F-B48E-4535-AAC2-585AD8925B14@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_78E41230-75EC-4070-8A74-1FCE9BE932BD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 24 Feb 2020 10:13:28 -0800
In-Reply-To: <CAH_hAJFF-o_iPzU-DxvjC2YafgTnep1xCW9pnsiRvuLncjWD0g@mail.gmail.com>
Cc: Rob Sayre <sayrer@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Cory Benfield <cory@lukasa.co.uk>
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrledtgdduudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpedftfhohicuvfdrucfhihgvlhguihhnghdfuceofhhivghlughinhhgsehgsghivhdrtghomheqnecukfhppeeikedrvddvkedrkedurddvheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedruddrgegnpdhinhgvthepieekrddvvdekrdekuddrvdehpdhrvghtuhhrnhdqphgrthhhpedftfhohicuvfdrucfhihgvlhguihhnghdfuceofhhivghlughinhhgsehgsghivhdrtghomheqpdhmrghilhhfrhhomhepfhhivghlughinhhgsehgsghivhdrtghomhdpnhhrtghpthhtohepihgvthhfqdhhthhtphdqfihgseiffedrohhrgh
Received-SPF: pass client-ip=23.83.209.62; envelope-from=fielding@gbiv.com; helo=fossa.birch.relay.mailchannels.net
X-W3C-Hub-Spam-Status: No, score=-6.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1j6IEl-0003qj-Iy a076e2e63d69296ae6e0c058d5368c08
X-Original-To: ietf-http-wg@w3.org
Subject: Re: GET / DELETE request bodies
Archived-At: <https://www.w3.org/mid/9C9C0E9F-B48E-4535-AAC2-585AD8925B14@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37382
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 Feb 24, 2020, at 8:19 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> On Mon, 17 Feb 2020 at 18:44, Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>> wrote:
>> 
>>> On Feb 17, 2020, at 1:53 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
>>> 
>>> The semantic requirement missing is that DELETE bodies have no
>>> spec-defined semantics. This is not that they can't have semantics, or
>>> that they shouldn't have spec-defined semantics, only that no
>>> specification has ever said what a body in a DELETE request means.
>> 
>> FTR, this is a common misinterpretation, but that is not what it says and
>> certainly not what it means.
>> 
>> They have no semantics in the sense that a body cannot change the meaning
>> of a received request. They are absolutely forbidden to have any impact
>> whatsoever on the processing or interpretation of the request aside from
>> the necessity to read and discard the bytes received in order to maintain
>> the message framing. The only reason we didn't forbid sending a body is
>> because that would lead to lazy implementations assuming no body would
>> be sent.
>> 
>> This has always been the case for HTTP and GET/HEAD/PUT/DELETE.
>> They were defined that way so that the URL would identify the resource
>> and intermediaries would not have to delve into the body to reinterpret
>> the semantics defined by method and header fields.
> 
> I'm finding this...confusing. Did you mean to put PUT in that list?
> Because RFC 7231 doesn't say bodies in PUT have no defined semantics,
> and it's distinctly not like the others in your list. Was CONNECT what
> you had in mind instead?

Er, no, I was thinking about the 1:1 relationship in the identifier and made that all confusing ...
PUT sends a representation in the request body, so the body exists but does not change the
semantics of PUT.  PATCH and POST would be the counterexamples where the recipient has to
process the body in order to determine the request semantics.  CONNECT is just weird.

....Roy