Re: Digest: use in requests

["Roy T. Fielding" <[e-mail]>]

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

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?

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