[tests-only] Upload post processing #2963
Conversation
kobergj
force-pushed
the
UploadPostProcessing
branch
12 times, most recently
from
c2b518c to
b2d145e
Compare
kobergj
force-pushed
the
UploadPostProcessing
branch
from
b2d145e to
33b81e8
Compare
kobergj
force-pushed
the
UploadPostProcessing
branch
from
33b81e8 to
2ef412d
Compare
|
related: owncloud/ocis#214 (comment) |
|
@butonic should we rename the steps? Not sure if that was a call to action or just an extra info 😄 |
| @@ -708,6 +708,14 @@ func mdToPropResponse(ctx context.Context, pf *XML, md *provider.ResourceInfo, p | |||
| Propstat: []PropstatXML{}, | |||
| } | |||
|
|
|||
| if status := utils.ReadPlainFromOpaque(md.Opaque, "status"); status == "processing" { | |||
| response.Propstat = append(response.Propstat, PropstatXML{ | |||
| Status: "HTTP/1.1 425 TOO EARLY", // TODO: use proper status code | |||
There was a problem hiding this comment.
Yeah, 425 is about replay attacks and the Early-Data header.
IMO [202 Accepted] would be the correct Status for a resource that is still being uploaded:
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.
But existing desktop clients might try to download files with a 200 status ... @TheOneRing what would desktop clients do with status 202? ignore the file? would be great for now...
I rember discussing with @dragotin that pre/postprocessing effectively locks the file and 423 Locked is the better Status ... hm although Locked would mean the user can unlock the file, which is not true ... Maybe 202 still is the right response after all? Together with a Location header to a websocket or Long polling endpoint ...
There was a problem hiding this comment.
I'm pretty sure to guess what a 423 will cause.
For everything indicating ok I'd expect a download to be triggered. If you need more info I'd need to dig deeper.
There was a problem hiding this comment.
As discussed in cross platform meeting we will stick with the 425 status code for now. We can revisit that decision later.
Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com> add changelog Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com> make postprocessing configurable Signed-off-by: jkoberg <jkoberg@owncloud.com> set node status only through node pkg Signed-off-by: jkoberg <jkoberg@owncloud.com>
kobergj
force-pushed
the
UploadPostProcessing
branch
from
0b7d407 to
a9e3435
Compare
| ) | ||
|
|
||
| // Tree is used to manage a tree hierarchy | ||
| type Tree interface { |
There was a problem hiding this comment.
can't you use the Tree interface from decomposedfs.go?
There was a problem hiding this comment.
I'd love to. But decomposedfs imports upload pkg. So if I import decomposedfs in upload it won't build any more.
There was a problem hiding this comment.
We could use the tree interface from here in decomposedfs. But I don't see the benefit in that...
|
@dragotin @kobergj I was trying to find an issue where we decide how to implement this, eg the status to return to clients for uploads that are in progress. If and how to return the current progress in the propfind (or only via graph) etc. It is not an ADR either ... did you discuss and design something off the record? My find-related-issue-fu only came up with owncloud/ocis#214 (comment), which is why I linked it here. Maybe we can clarify there what clients can expect from the server and how we want to handle this? |
Signed-off-by: jkoberg <jkoberg@owncloud.com>
kobergj
force-pushed
the
UploadPostProcessing
branch
from
a9e3435 to
eb447f5
Compare
Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com>
kobergj
force-pushed
the
UploadPostProcessing
branch
from
57026f2 to
45fde95
Compare
Signed-off-by: jkoberg <jkoberg@owncloud.com>
kobergj
force-pushed
the
UploadPostProcessing
branch
from
f002c14 to
0a090e1
Compare
This reverts commit 0a090e1.
Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com>
Signed-off-by: jkoberg <jkoberg@owncloud.com>
|
cool! |
Introduces post processing of items after upload