- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 17 Feb 2020 13:59:34 +0100
- To: Cory Benfield <cory@lukasa.co.uk>, Rob Sayre <sayrer@gmail.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 17.02.2020 10:53, 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.
> They never have. The result of this is that DELETES with bodies aren't
> interoperable: while they may work with a specific service, that
> service has defined a special-case for itself. Arbitrary
> implementations are free to ignore DELETE requests with bodies, or
> reject them, or do anything else they like with them.
>
> The relevant section of the HTTP specification that discusses what it
> means for a message body to have semantics is RFC 7231 ยง 3.3 (Payload
> Semantics) (https://tools.ietf.org/html/rfc7231#section-3.3).
> ...
I personally find that line of argument incredibly weak.
1.) What about OPTIONS then? I don't see a significant difference
between the warnings that we have for OPTIONS ("not defined here but may
be in the future") and DELETE ("has no defined semantics so might be
rejected") - in particular as the latter statement was a change from 2616...
2) We *claim* that DELETE with request body is not interoperable; but do
we actually have proof of that? What problem are we solving by making
this change?
Best regards, Julian
Received on Monday, 17 February 2020 12:59:49 UTC