Re: GET / DELETE request bodies

"Roy T. Fielding" <> Mon, 17 February 2020 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC521120863 for <>; Mon, 17 Feb 2020 10:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 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, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7XScGnliMeGv for <>; Mon, 17 Feb 2020 10:48:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D67E0120860 for <>; Mon, 17 Feb 2020 10:48:06 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j3lO3-0004Ra-Cs for; Mon, 17 Feb 2020 18:44:55 +0000
Resent-Date: Mon, 17 Feb 2020 18:44:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j3lNx-0004Qj-5M for; Mon, 17 Feb 2020 18:44:49 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j3lNv-00084E-Ew for; Mon, 17 Feb 2020 18:44:49 +0000
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 57B98600DDA; Mon, 17 Feb 2020 18:44:34 +0000 (UTC)
Received: from (100-96-215-16.trex.outbound.svc.cluster.local []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id 4A38D6010B8; Mon, 17 Feb 2020 18:44:33 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ([TEMPUNAVAIL]. []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.5); Mon, 17 Feb 2020 18:44:34 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Macabre-Cooperative: 3d6d6f462492e6c1_1581965074082_3096896470
X-MC-Loop-Signature: 1581965074082:4074443080
X-MC-Ingress-Time: 1581965074082
Received: from (localhost []) by (Postfix) with ESMTP id 7C6B99FCF5; Mon, 17 Feb 2020 10:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=gBE0+3X6Q88WJxm+oJ7pTjEXDcI=; b=U0MvdA8K+EMQSpIGkOXmNSPxrVKX TahhrDdlFHlJZOdBlmDjbiSTVmqt/Mh8xmbVtnn3TfOtPSutA+2HpsyihsWGxV4B VVFBJC/uclgH9rNTpl2lHG/dQmJKZ3dBotNZNKfOwF9M2w3SUrC6q98b5rEgAoQl +cpAGtSkSVUAUdE=
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 50F559FCED; Mon, 17 Feb 2020 10:44:28 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
X-DH-BACKEND: pdx1-sub0-mail-a20
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Mon, 17 Feb 2020 10:44:25 -0800
Cc: Rob Sayre <>, " Group" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Cory Benfield <>
X-Mailer: Apple Mail (2.3445.104.11)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrjeeigdduudejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthejmhdthhdtvdenucfhrhhomhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqeenucfkphepieekrddvvdekrdekuddrvdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurdegngdpihhnvghtpeeikedrvddvkedrkedurddvhedprhgvthhurhhnqdhprghthhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqedpmhgrihhlfhhrohhmpehfihgvlhguihhnghesghgsihhvrdgtohhmpdhnrhgtphhtthhopehivghtfhdqhhhtthhpqdifghesfiefrdhorhhg
Received-SPF: pass client-ip=;;
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, 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: 1j3lNv-00084E-Ew dfa0ca961d61977a290b82173eb6c2df
Subject: Re: GET / DELETE request bodies
Archived-At: <>
X-Mailing-List: <> archive/latest/37358
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Feb 17, 2020, at 1:53 AM, Cory Benfield <> 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.

The other request methods are more like POST and the original SEARCH.
OPTIONS was defined much later with the intent of maybe needing a
body for more complex queries, but we didn't have the energy or need
to actually define one.