Open nicholas-wilson-au opened 1 week ago
I'm moving this to the ocis repo because I think Web is handling things correctly. When uploading a 0 byte file, the server is missing the Location
header in the response.
In a regular context Uppy will retry the exact same request again. The server includes the Location
header the second time. In a public link context with only upload permissions (= file drop) however, the server never responds with a location header.
@JammingBen How the Web uses the location in this case? The zero-byte file is simply created, it is not going to the tus.
The underlying lib we use (Uppy) does something with this header, I can't say what exactly. I'd need to check the vendor code.
But why is oCIS sending a Location
header on the second try then? Isn't it possible to always send it?
I did some further debugging. As mentioned above, the issue is that the server doesn't send a Location
header in the response because zero byte files are simply being touched without tus being involved.
I tried to handle this exception in Web but it's not that easy. Web is assuming that all file uploads are being handled via tus (when enabled) and therefore expects the server to follow the tus protocol under any circumstance. If this isn't the case, it might fail. IMO it's up to the server to provide a clean API here.
cc @2403905 @butonic
Describe the bug
Uploading a 0kb file to a secret file drop results in an error however the file appears in the folder multiple times.
Steps to reproduce
Expected behavior
A successful upload of a single file or an error saying the file is empty.
Actual behavior
An error is shown saying upload failed but the upload was successful.
Setup
https://ocis.ocis-keycloak.rolling.owncloud.works/