Consider need for MOVE verb

[michielbdejong]

This is an issue that came up on https://www.ietf.org/mailman/listinfo/storagesync (2015-12-02 message from ietf at hugo dot labkode dot com):

There is one requirement that all synchronisers need to handle: moving
resources. In this spec the alternative of a WebDAV MOVE is not
specified.

It is true that a MOVE could be replaced with a DELETE + UPLOAD but that
is not acceptable in most cases due to the inefficiency of such
operation (cpu, bandwidth consumption ...)

Is there a plan to support such basic feature?

[raucao]

... and/or COPY (as we might want to use that to publish things in the public dir).

[untitaker]

As mentioned elsewhere, additional HTTP verbs are relatively hard to configure in practice, so support for MOVE should be optional IMO and clients should be required to fall back to DELETE + UPLOAD.

[ghost]

hard to configure?

Whether or not MOVE is important is really about what RS is about. If you see it as a JS storage for (private) app data MOVE Is not needed. If you see it as more than that and also as something where you store your RAW phone pictures, MOVE is a MUST. Whether or not you call it PATCH or MOVE or POST doesn't really matter :) I think we should first reach an agreement on what RS is about and then from that it follows if we should add it or not, details on how are for later :)

[untitaker]

Sorry I was wrong in a way: By default, nginx doesn't allow PUT as well, see http://nginx.org/en/docs/http/ngx_http_dav_module.html, so it doesn't matter whether we introduce MOVE as an additional verb.

Still the argument remains on whether MOVE is so essential that every server MUST support it. Perhaps we should go with "SHOULD support" for the server, and "MUST NOT rely on" for the client.

[raucao]

Sorry I was wrong in a way: By default, nginx doesn't allow PUT as well, see http://nginx.org/en/docs/http/ngx_http_dav_module.html, so it doesn't matter whether we introduce MOVE as an additional verb.

In practice web servers are only run in front of RS app servers, though. At least at the moment. We plan to build an RS server as a Lua module for Nginx, but it goes without saying that adding a correct Nginx config is the least of your deployment woes with that. ;)

I think if we have good enough example configs for web servers, it shouldn't be much of a problem. People have to deal with TLS and that's more of a pain than adding MOVE or COPY I think.

[untitaker]

Here's what I was getting at: http://programmers.stackexchange.com/a/193826 Anecdotally, php's builtin server is very presumptuous about methods it doesn't recognize. This particular bug is fixed, but the parser itself is written in a way such that it doesn't recognize arbitrary methods.

I consider this point to be less important nowadays though, I think using methods that are already used by WebDAV will work fine.

[raucao]

It would also be possible to define a PUT alternative, as for example OpenStack's Swift object storage does:

http://developer.openstack.org/api-ref/object-storage/index.html?expanded=copy-object-detail#copy-object