Re: Byte range PATCH

Austin William Wright wrote ---



>

> Like Julian said, the methods in HTTP Semantics are not an

> endorsement of what methods you should or should not use.

>



I've certainly never considered them to be. I also consider <acronym> valid.


>

> HTTP Semantics only describes the essential semantics, and 

> PATCH is not essential for understanding HTTP. It’s fine as a 

> separate document.

>







I have no problem with that if it's the consensus of the WG. But it does lead to some confusion in developer circles.


>

>>

>>>
>>> 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.

>







Not on my server! If a UA tries to PATCH a resource that does not list PATCH in an Allow header, it's going to get a 501 response?



>

> PATCH is useful because there's exactly one interpretation.

>



Exactly what I'm trying to say, limit it to update not *both* update and create.


>
> The only meaning that POST has is the one that the server

> gives it, and that’s not always transparent or useful.

>



That holds true for all request methods. Even non-idempotent GETs exist in the wild. My point is, that since origin servers can and will do anything, developers should strive for transparency and usefulness to intermediaries. Using PATCH to create, means intermediaries must determine whether or not it's safe (not just idempotent) to pass on the request. Or expose a lot more attack surface area, as creation requires considerably more server resources than updating.


>

> 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.

> 



PUT with no entity-body may be used to mint a resource with ACCEPT: Patch for progressive uploading of a large file. It's a very small round-trip, the latency of which becomes progressively meaningless the larger the file.


> 

> PATCH lets you express a PUT in terms of the existing

> resource

>



What 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.

>



Maybe not, but is there any reason a client can't make its initial request an empty PUT? Response code may be 202. Until it's 200 and reports Allow: PATCH there's no reason for the client to continue, because that may never happen. Which lets me limit allowed methods on undefined resources. Even if I'm wrong about that cuts down on "attack surface area".



On my bespoke calendar app, if Jan. 6th 2021 needs updating to say anything other than Wednesday about that day, it's a PUT. Unless our next Congress declares that date Donald Trump Day, retroactive to 2021, in which case I'd PATCH /2021/jan/6 with a code update, without restarting the app but definitely expiring any affected cached output. That's just how I roll, YMMV.



>

> 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.

>



Right. Starting a PATCH request at byte zero, is much less confusing to me if it's update not create. But, hey, if I get no traction on this then I'll shutup about it and try to figure out why I'm the only one thinks it's confusing.



I sometimes get caught up in my own little world, where packed protocol headers/trailers might be limited to characters that exist in the binary morse spec so I can compress them into progressive 8-bit PNG files, allowing prioritization to be well-defined by that media type and costing very few bytes over the wire, what with site-wide redundant headers being linked and cached.



IOW, I do experiment a lot, and that's why I don't like using PATCH to create. I tried it and found it to be more trouble than it was worth, to the point of having a problem with it in general, not just for my use-cases.



>

>>

>> 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.

> 



Sorry for the misunderstanding, but I was asking about "prior art." It's a legitimate question not intended to be critical of anything. Heck it was just the other month I advocated against cleaning some old stuff out of the header registry because 25 years old, when I only recently found a use for them.


>

> 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.

>







Fileops assume a 1:1 mapping between resource and file, which does not exist in HTTP, so why is it being enforced in RFC 5789. Over the network, a series of patches pertaining to nothing, should be rejected.



>

> A PATCH is not necessarily an “update”. (Not everything

> must fit neatly into CRUD operations.)

>



I've never intimated they should. REST != HTTP != CRUD. However, discussions of HTTP do require the linguistic frameworks provided by REST and CRUD. My objection to using PATCH for create isn't based on CRUD. Separation of concerns is the over-arching paradigm for me in this discussion.


>

> 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).

>



404 *is* a resource state, not a lack thereof. That state may be altered by adding a searchbox, without defining the resource as existing. I'd like to do that over-the-wire in a transparently obvious way, trusting PATCH will not change the resource state to 200 OK. Just as I trust a no-entity-body PUT request will update headers, and not be considered a DELETE.



At least as far as I can spit. Which is further than I can drool.


>
> 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 we view PATCH as corollary to diff/patch/filesystem, sure. But if we consider DARCS patch theory, the resource (of patch files) must first be created, and may not be where we store the patch itself (it may be linked to). It's a different precedent with different essential behavior. To me it's more correct for HTTP because it comes from the world of distributed versioning not fileops.



-Eric