Return hashes of uploaded content for dav uploads

[icewind1991]

hashes are set in "X-Hash-MD5", "X-Hash-SHA1" and "X-Hash-SHA256" headers.

these headers are set for file uploads and the MOVE request at the end of a multipart upload.

cc @tobiasKaminsky

[tobiasKaminsky]

Nice :-)
I unfortunately cannot answer my questions via looking into code:

• will this fail upload, if checksum mismatch? (I do not think so)
• how can I get the hash value for existing files?

[icewind1991]

• no
• this pr doesn't add that

This only returns the hash of the uploaded content so clients can detect corrupted transfers

[rullzer]

To give a bit more context ;)

will this fail upload, if checksum mismatch? (I do not think so)

No but you can detect it at least client side. And do something.

how can I get the hash value for existing files?

Adding this is tricky. Just imagine on a big instance and everybody starts to request the hash of several GB files. This could easily kill the server.

Long story short. This is a step in the right direction but not the full fix at all.

[tobiasKaminsky]

will this fail upload, if checksum mismatch? (I do not think so)

No but you can detect it at least client side. And do something.

So I would upload the file, then download info of it, compare hash.
If not same, I have to remove it, and show an error to user.

That sounds a bit too complicated… Can't we adjust it so that server will compare hash and if it is not the same refuses the file to be moved and returns an error.

Adding this is tricky. Just imagine on a big instance and everybody starts to request the hash of several GB files. This could easily kill the server.

True. So we can reliable use this for all files, once each upload and change on server computes a hash sum?
(background of this this to have a reliable way that a file to upload does not exist in a folder)

[icewind1991]

Keeping hashes for files stored on the server is a much more complex problem then just returning a hash from uploaded content.
In order to keep hashes for stored files we need to be 100% sure that we update (or invalidate) the hash for every change made to the file on the server

[rullzer]

That sounds a bit too complicated… Can't we adjust it so that server will compare hash and if it is not the same refuses the file to be moved and returns an error.

That is a next step. But a lot more complicated and not covered in this PR.

[tobiasKaminsky]

Keeping hashes for files stored on the server is a much more complex problem then just returning a hash from uploaded content.
In order to keep hashes for stored files we need to be 100% sure that we update (or invalidate) the hash for every change made to the file on the server

Totally understandable.

That is a next step. But a lot more complicated and not covered in this PR.

Then I will wait until the next step, as we otherwise would implement the error handling logic on client side and then later can remove it again.
But really nice to see improvement in this area :-)

[rullzer]

@icewind1991 mind to fix ci so we can get this in as well?

[kesselb]

So I would upload the file, then download info of it, compare hash.

@tobiasKaminsky the calculated hash is part of the response of the move or put operation. No need to download the file info.

[kesselb]

LGTM 👍

Needs a rebase due those code style changes.

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation. No need to download the file info.

True, but still this needs to be done on client side.
In my opinion a wrong hash sum must lead to an upload error. But as Roeland said, this will happen hopefully in next step.

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…

[tobiasKaminsky]

@tobiasKaminsky the calculated hash is part of the response of the move or put operation.

I only see it as a response header in put operation, but not in final move (of chunked upload)?

Nevermind. I did something wrong, but now it works…