Panic when downloading

[refs]

When downloading via phoenix, we get 502 in CERN's setup.
Logs: https://gist.github.com/ishank011/2ec204692a6cc1092db68b743857fdf6

[refs]

@ishank011 could you provide a bit more input? 👯 I suspect that accounts middleware is acting funny. It would be helpful if you could post the phoenix request since such middleware can be bypassed, and I would like to see what the implications are.

[refs]

I tried killing the usual suspect, the ocis store, but I'm not reproducing the issue that way. I think the smoking gun is the accounts middleware, as your logs show

[ishank011]

@refs Clicking on a file first sends a HEAD request which returns successfully

Request URL: https://cbox-spare-02.cern.ch:9200/remote.php/webdav/hello.txt
Request Method: HEAD
Status Code: 200 OK
Remote Address: 127.0.0.1:12345
Referrer Policy: strict-origin-when-cross-origin

followed by one to the endpoint, which returns a 502

Request URL: https://cbox-spare-02.cern.ch:9200/ocs/v1.php/cloud/user/signing-key
Request Method: GET
Status Code: 502 Bad Gateway
Remote Address: 127.0.0.1:12345
Referrer Policy: strict-origin-when-cross-origin

The complete logs are here https://gist.github.com/ishank011/2ec204692a6cc1092db68b743857fdf6
I don't see any others.

Also, all these background requests remote.php/dav/files/iarora/abc.txt?a=1&c=424293cbda57c4ed5931b8a011f7ea59&preview=1&scalingup=0 return a 500, and I see that these return a 404 at https://ocis.owncloud.works/.

One more thing. How do we disable tus from phoenix?

[ishank011]

As @butonic mentioned, this should be handled by reva but apparently, it is somehow being redirected to ocis (or vice versa).

[ishank011]

But looking at https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocs/handlers/cloud/user/user.go, this won't be the issue, as it should always return 200

[ishank011]

u.Opaque.Map["roles"] is probably nil here https://github.com/owncloud/ocis/blob/master/ocis-pkg/middleware/account.go#L70

[ishank011]

Yep. opaque:<map:<key:\"gid\" value:<decoder:\"plain\" value:\"2763\" > > map:<key:\"uid\" value:<decoder:\"plain\" value:\"125677\" > > >

[butonic]

@ishank011 regarding TUS: as long as TUS headers are present ocis web will use them. owncloud/owncloud-sdk#461

Which means that on EOS which does not support TUS the ocdav handler should not announce them in PROPFIND headers. which is currently hardcodet to true: https://github.com/cs3org/reva/blob/a7bf52ba4cf145baeb4b72d5dca485c731d5c1a7/internal/http/services/owncloud/ocdav/propfind.go#L192-L197

We could return capabilities like this in a ResourceInfo Opaque propery ... because it might change from file to file ...

[ishank011]

@butonic oh okay. I added a change which fixes the capabilities response in ocs cs3org/reva#1331. Can we somehow propagate that to ocdav? Otherwise, I'll add the opaque property to EOS resources

[butonic]

forget the capabilities endpoint. it has to die for anything related to files. having a single endpoint does not make sense because the capabilities might change with every tree, maybe even for every folder and file.

TUS ist a good example. It really is specific to the folder and we should announce it in the PROPFIND / HEAD requests using the proper headers. So I strongly vote for opaque properties.

[ishank011]

Cool, I'll make the change. Thanks for looking into this!

[butonic]

@ishank011 we could add tus support to https://cs3org.github.io/cs3apis/#cs3.storage.registry.v1beta1.ProviderInfo.Features