Download broken for azure store

[quality-leftovers]

Describe the bug
Changes in #1272 seem to have broken the download from an azure store.

Since Offset provided by GetOffset is used in unrouted_handler to determine content-length the content-length for an uploaded blob is now always 0, because there are no more uncomitted blobs.

To Reproduce

• Upload blob using azure store
• Try to download blob
• Get 204 no content

Expected behavior
Content is served

Setup details
n.a.

[Acconut]

Thank you for reporting this! /cc @MariuszBartnik who wrote the PR you mentioned as a potential cause.

Would you be willing to look into a potential bug fix for this? I don't use Azure Storage on my own, so it's hard to test it out by myself.

[quality-leftovers]

I see @MariuszBartnik is already on it. But I can support.

Maybe we should clarify whether the ability to overwriting existing blobs using the same id which is possible now should be default beavior, or if we should have a flag on the store like allowOverwrite?

In the past trying to PATCH a complete file returned ERR_MISMATCHED_OFFSET. Now it will overwrite the existing one. If you are not using versioned blobs this allows a client to effectivtly "remove" previously uploaded data.

[MariuszBartnik]

In the past trying to PATCH a complete file returned ERR_MISMATCHED_OFFSET. Now it will overwrite the existing one. If you are not using versioned blobs this allows a client to effectivtly "remove" previously uploaded data.

This depends on how you are handling the upload If you are sending the entire file in a single request, then it would work as you described. If you were sending multiple chunks however then the error would be thrown only for some of the actions. If the file which you used for update was bigger than the original, this might lead to appending some bytes to the previously uploaded file and making it corrupted.

I believe a better option for preventing user from overwriting previous file is to use the hooks and control the path, where the file is saved, changing it for every upload.

[quality-leftovers]

I just re-tested the changes and it was really was a POST which re-used the same id and not the PATCH which overwrote the file. Probably had the wrong method set in my test REST client.

Verified that upload and download work in our setup with the changes and it looks good (from an azurestore centric POV)