Provide permissions and ownerId in PUT request when uploading a new file

[mpivchev]

On iOS and Android we need to handle some UI after we upload a file that requires us knowing the permissions for said file. This works in already PROPFINDed files, but a new file does not get PROPFINDed immediately for performance reasons. Currently we would have to fetch the whole metadata for a directory to know the permissions of new files, which is way too expensive, especially since we have to do this for every new file (imagine uploading 500 files at once).

Feature request:
After a PUT request for a new file we receive the e-tag and file-id. Is it possible to also receive the permissions and ownerId through that as well? This way we would not need to request the whole metadata for current directory every time.

An example would be Oc-Permissions: SVGDM and Oc-OwnerId: xxxxxxx in the header. It can also be part of the body.

Use case:

1. We need permissions to determine which actions to show when a file is uploaded. Example is hiding the "Delete file" option when user has no delete permission. Another example is removing "Rename file" if file has no edit permission. This is not possible for a new file, as we did not PROPFIND it.

2. We need the OwnerId to display owner the moment a file is uploaded. Currently a new file does not show owners until the list is refreshed and PROPFINDed.

[mpivchev]

@alperozturk96 @tobiasKaminsky

[salmart-dev]

Hello @mpivchev, I see that the web client does a PROPFIND for the uploaded file immediately after the upload. Is there any reason why this cannot be done in the app client as well, instead of waiting for a PROPFIND for the whole directory which can be expensive?

[marinofaggiana]

Hello @mpivchev, I see that the web client does a PROPFIND for the uploaded file immediately after the upload. Is there any reason why this cannot be done in the app client as well, instead of waiting for a PROPFIND for the whole directory which can be expensive?

Hi Salvatore, the reason is very simple and is called resource optimization. Each PROPFIND request requires client, network, and server resources. If it's not needed, it's all wasted energy and CO2. So, if adding the field to the response isn't a problem for the server, I don't see why not.

Note: If I send 1,000 files, 1,000 PROPFINDs are useless, and if you see in the clients how many lines of code are needed to create a PROPFIND request, perhaps on the server side you would try to apply different logic.

[salmart-dev]

Hi Salvatore, the reason is very simple and is called resource optimization. Each PROPFIND request requires client, network, and server resources. If it's not needed, it's all wasted energy and CO2. So, if adding the field to the response isn't a problem for the server, I don't see why not.

Note: If I send 1,000 files, 1,000 PROPFINDs are useless, and if you see in the clients how many lines of code are needed to create a PROPFIND request, perhaps on the server side you would try to apply different logic.

Hi @marinofaggiana, you're right—doing many PROPFIND requests would waste server resources too. Looking back at my message to @mpivchev, I realize I completely missed the point I actually wanted to make and ended up asking a rhetorical question.

What I’m really trying to understand is:

• Will this change be reusable by other clients?
• Will any relevant data still be missing? If so, would it be possible to return that too, so that all clients can avoid an extra PROPFIND?

If there's a way to implement this in a way that benefits multiple clients, I’d like to avoid doing something ad hoc. I'll check with my team and see if we go for the cheap solution or something more flexible, provided it can serve more clients.

[come-nc]

I’m failing to find documentation about what the answer to a WebDAV PUT request is supposed to look like.
Does anyone have a pointer for that?

[salmart-dev]

@come-nc https://www.rfc-editor.org/rfc/rfc4918#section-9.7.1

[mpivchev]

@come-nc I have sent you an example put request in private

[come-nc]

@come-nc https://www.rfc-editor.org/rfc/rfc4918#section-9.7.1

That explains what the PUT request does, but I do not see what the response is supposed to look like.

[salmart-dev]

@come-nc https://www.rfc-editor.org/rfc/rfc4918#section-9.7.1

That explains what the PUT request does, but I do not see what the response is supposed to look like.

From that description I would assume that there is no definition on how a response is supposed to look like. That part only states that if a PUT is done on an existing item, it replaces the GET request for the same resource, which I guess also means the response is the one of the GET request, but other than that nothing else seems to be mentioned about it.