Subject: Re: Digest: use in requests

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Jan 2021 09:41:33 +1100

On Wed, Dec 30, 2020, at 00:38, Julian Reschke wrote:
> "An origin server that allows PUT on a given target resource MUST send a
> 400 (Bad Request) response to a PUT request that contains a
> Content-Range header field (Section 4.2 of [RFC7233]), since the payload
> is likely to be partial content that has been mistakenly PUT as a full
> representation. ..." --
> <https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.3.4.p.11>

This seems like a problem in the face of the examples Lucas has shared: are we going to correct reality or the spec?

---

From: Roy T. Fielding <[email-masked]>
Date: Sun, 3 Jan 2021 17:22:20 -0800

On Jan 3, 2021, at 2:41 PM, Martin Thomson <[email-masked]> wrote:

For every non-interoperable private implementation of partial PUT
there are ten implementations that will simply store the partial entity
several times. That's reality and it cannot be specified (post-1996)
in an interoperable way other than to say "don't do that".

Of course, people who control both sides of an API will always try
to improve the interface in a way that makes their application entirely
dependent on a single non-standard feature that has no hope of
interoperable implementation. That's also our reality.

My perspective is that the entire problem is based on looking at
HTTP in the wrong way: what the server should be doing is telling
the client how to construct the right URL for each PUT, such that
sub-resources can compose a larger resource (another URL).
So, I didn't bother to "solve" it like a remote filesystem.
However, that too requires a common standard definition for
how a link template is conveyed and how clients are instructed
to use it, and the latter is way down on my list of things that
I will probably never find time to do.

Defining several simple and obvious PATCH formats would have
solved this immediately, 20 years ago, but that didn't happen either
because the entire industry was getting busy with XML, for reasons.
And then it had to be replaced by JSON anyway.

The reality we face is that people will continue to do the obvious
but totally wrong implementation over and over, given the lack of
any well-documented alternatives. It doesn't help that some
people want this functionality for editing whiteboard-style and
others want it for continuation after a bad write and still others
want it for multiple writes in parallel because, FFS, why not?

And so we have all of these implementations that claim to be
using Content-Range to implement partial PUT where it actually
triggers something weird and unspecified on the backend
involving GCP or S3 buckets or whatever, and they might look
like they are doing something similar to what we want to define,
but maybe sending them the wrong input will take down an
entire AWS region instead of posting a cat meme.  IDK.

Cheers,

....Roy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Jan 2021 14:47:13 +1100

> in an interoperable way other than to say "don't do that".

Yes, this is clearly the motivation for the existing spec text.  My question was whether you want to avoid using such absolute language.  Or is there generic text somewhere that says "some resources play fast and loose with this protocol, that's just how it is"?