Re: Byte range PATCH

> On Aug 8, 2022, at 23:03, Eric J Bowman <mellowmutt@zoho.com> wrote:
> 
> >
> > PATCH is not causing anyone any trouble.
> >
> 
> Then why is it the redheaded stepchild of HTTP methods, defined by its own RFC as opposed to being part of the core protocol?

Like Julian said, the methods in HTTP Semantics are not an endorsement of what methods you should or should not use.

HTTP Semantics only describes the essential semantics, and PATCH is not essential for understanding HTTP. It’s fine as a separate document.

> >
> > This proposal does not "overload” anything. If anything, 
> > I’m writing this to avoid overloading PUT or POST with 
> > semantics that may be misunderstood by origin servers.
> >
> 
> Did you mean to say intermediaries? No origin server I've ever coded has ever misunderstood anything about the application it's serving, let alone the intended semantics of a chosen method.

No, I mean origin. User agents are not limited to using your interface; they may use any part of the uniform interface, including PATCH, even if the server didn’t indicate so.

PATCH is useful because there's exactly one interpretation. My user-agent can know if it’s idempotent to safely retry the request. In contrast, I cannot guess at what kind of POST request I would have to send you to do the same thing. The only meaning that POST has is the one that the server gives it, and that’s not always transparent or useful.

With PATCH, it’s guaranteed; the worst thing that happens is the server returns 405, 415, or 501; in that case I have to fall back to a PUT request to make the intended changes; which may be wasteful of bandwidth if the file is very large. PATCH lets you express a PUT in terms of the existing resource, so you only need to describe the parts that change. There’s no reason that creation can’t be a change that a client might want to express.

If byte range PATCH doesn't exist, then people might overload PUT with Content-Range headers, or use a POST request, which lack a standardized meaning at best, and can cause data corruption at worst.

> >
> > The PATCH semantics, by contrast, are being used exactly 
> > as intended and understood.
> > 
> 
> Sort of. RFC 5789 included "resource creation" sure. But do you have any examples of PATCH being used that way in the wild?

This proposal should be a sufficient example. If there’s no server that would misunderstand it, and if there’s a client that finds it useful, then there’s no problem.

Also, the “patch” command works exactly this way. The first patch in a series of patches necessarily creates the file. This should not be universe-warping.

> I can't help but wonder if there isn't a good reason it took 12 years for this issue to come up. Like maybe the RFC got it wrong? PATCH's "update" semantics are understood, and (perhaps widely) used as intended.

A PATCH is not necessarily an “update”. (Not everything must fit neatly into CRUD operations.)

PATCH allows a client to alter the current state of the resource according to enclosed instructions; it can represent any PUT operation that takes into account the current state of the resource (including lack thereof).

> Creation, not so much! Never occurred to me that it would be controversial, to think that updating something pre-assumes its existence, and should report an error otherwise. Creation via PATCH falls under my definition of "silent error correction" which makes it a "bad thing" in the HTTP universe.

In a series of patches representing a file’s change history, literally the very first one creates it. Not only does this have precedent, this is essential behavior.

If you don’t want a PATCH request to create a file then either (1) don’t use a media type that does that, or (2) add `If-Match: *` to your request.

Thanks,

Austin.