Shares: server reported no etag

[sushmita56]

Description

The error Shares: server reported no etag comes up as soon as I added the OCIS-traefik server on the ownCloud desktop app for manual testing.

Screenshot

[michaelstingl]

Same with ocis.ocis-traefik.latest.owncloud.works:

% curl 'https://ocis.ocis-traefik.latest.owncloud.works/remote.php/dav/files/einstein' \
-X 'PROPFIND' \
-H 'Content-Type: application/xml; charset=utf-8' \
-H 'Accept: application/json, text/plain, */*' \
-H 'Authorization: Bearer eyJhbGciOiJQUzI1NiIsImtpZCI6IiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJ3ZWIiLCJleHAiOjE2NDc4NjgxNDAsImp0aSI6ImU3aTcxR0lPQXZaN0UyRzhwX0t2N25HUWJiRGgwa3hKIiwiaWF0IjoxNjQ3ODY3NTQwLCJpc3MiOiJodHRwczovL29jaXMub2Npcy10cmFlZmlrLmxhdGVzdC5vd25jbG91ZC53b3JrcyIsInN1YiI6ImF4RnhwdW13cUlYUXJiSWtAS2tGeTNVSkRnR0JBTElpWkMxak1ZdllRYlVTNjU0OGliaVZieGJvMW5vNjdUdWNEWEZTUWVOV2dVOE44SzQzSlVoSERnZyIsImxnLnQiOiIxIiwic2NwIjoib3BlbmlkIHByb2ZpbGUgZW1haWwiLCJsZy5pIjp7ImRuIjoiZWluc3RlaW4iLCJpZCI6ImNuPWVpbnN0ZWluLG91PXVzZXJzLGRjPW9jaXMsZGM9dGVzdCIsInVuIjoiZWluc3RlaW4ifSwibGcucCI6ImlkZW50aWZpZXItbGRhcCJ9.aCdHo3ffmOAtMcGmO7uXlCtzAkDmfUOLNXKKurPWNHNkLrCtsd_jZjlH1QzN1ih6ks_nyINYdZ91eoD4zPJGDZEFbgcMEarfs4CJfDMoo0esA-QXBx9-qmgpHb2rFl9-D3N6lHjZ7XsmplmkLvfpIIODJ9VMAoqgTDrW-N_nugMceTguBNTrkqeMetpb04gqQ0o3IL27POVw19gKD1mvtrOSsFe1T0XJZRjnmGa-srItar8CduLXO7Qv6gUR1N0eu_N6nOI5yADXGmuImsOjRyK_D_GXBpqmP6II0PLafdektZEzFfMLjZMRVIsEASwMO0eB_efdpT144tdcRP4Neg' \
-H 'Accept-Language: en-GB,en;q=0.9' \
-H 'Accept-Encoding: gzip, deflate, br' \
-H 'Host: ocis.ocis-traefik.latest.owncloud.works' \
-H 'Origin: https://ocis.ocis-traefik.latest.owncloud.works' \
-H 'Content-Length: 436' \
-H 'Referer: https://ocis.ocis-traefik.latest.owncloud.works/files/spaces/personal/home?items-per-page=100' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15' \
-H 'Connection: keep-alive' \
-H 'OCS-APIREQUEST: true' \
-H 'X-Requested-With: XMLHttpRequest' \
-H 'X-Request-ID: 4fcd3223-dd3f-40de-8d22-06318707e6b7' \
-H 'Depth: 1' \
--data-binary $'<?xml version="1.0"?>\n<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">\n  <d:prop>\n    <oc:permissions />\n    <oc:favorite />\n    <oc:fileid />\n    <oc:owner-id />\n    <oc:owner-display-name />\n    <oc:share-types />\n    <oc:privatelink />\n    <d:getcontentlength />\n    <oc:size />\n    <d:getlastmodified />\n    <d:getetag />\n    <d:getcontenttype />\n    <d:resourcetype />\n    <oc:downloadURL />\n  </d:prop>\n</d:propfind>'  | xmllint --format -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2234  100  1798  100   436   9460   2294 --:--:-- --:--:-- --:--:-- 12141
<?xml version="1.0"?>
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/remote.php/dav/files/einstein/</d:href>
    <d:propstat>
      <d:prop>
        <oc:permissions>RDNVCK</oc:permissions>
        <oc:favorite>0</oc:favorite>
        <oc:fileid>4c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51</oc:fileid>
        <oc:owner-id>einstein</oc:owner-id>
        <oc:owner-display-name>Albert Einstein</oc:owner-display-name>
        <oc:size>0</oc:size>
        <d:getlastmodified>Mon, 21 Mar 2022 12:59:01 GMT</d:getlastmodified>
        <d:getetag>"cffabc9ae0896402efc40600346aba59"</d:getetag>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <oc:share-types/>
        <oc:privatelink/>
        <d:getcontentlength/>
        <d:getcontenttype/>
        <oc:downloadURL/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/einstein/Shares/</d:href>
    <d:propstat>
      <d:prop>
        <oc:permissions>S</oc:permissions>
        <oc:favorite>0</oc:favorite>
        <oc:fileid>a0ca6a90-a365-4782-871e-d44447bbc668!a0ca6a90-a365-4782-871e-d44447bbc668</oc:fileid>
        <oc:size>0</oc:size>
        <d:getlastmodified>Thu, 01 Jan 1970 00:00:00 GMT</d:getlastmodified>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <oc:owner-id/>
        <oc:owner-display-name/>
        <oc:share-types/>
        <oc:privatelink/>
        <d:getcontentlength/>
        <d:getetag/>
        <d:getcontenttype/>
        <oc:downloadURL/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

[micbar]

Good question. This occurs when there are no shares. As soon as we have some accepted shares the etag appears.

[butonic]

To be clear, I'd vote for clients to be more forgiving when there is no etag. Future implementations of storage spaces may not have an etag or an mtime. For example when accessing a tape archive. That being said a workaround on the server side is to always return an etag, either a random one or a static one, depending on what should be achieved.

IN this case however, I vote for hiding the share jail when there are no shares. The ListStorageSpaces should not return the storage space of type virtual when the user has no shares. It is ok ju just return an empty list then.

[micbar]

IMO we cannot change the clients out there.

So i vote for solution 2: only return a shares jail when there are shares.

[butonic]

I'm not saying wo change all the clients to fix this problem. All I am saying is that clients should be more forgiving. A resource does not have an etag. So what? That only means clients cannot decide when to descend into a folder. I think Postel's law applies: be conservative in what you do, be liberal in what you accept from others..

Desktop and mobile and even web clients could ignore the folder and only update local metadata when the user manually descends / explores the tree.

But that is a different issue and should be tracked elsewhere / at another time.

[michaelstingl]

This endpoint is backwards compatible, so folders need etags. Different story for the new spaces endpoint. Happy to discuss etag-less spaces.

[micbar]

@butonic so quick solution: always have an etag. Needs fix in beta.

[micbar]

@felix-schwarz @TheOneRing Is it also possible to not have a share jail when there are no shares?

[michaelstingl]

@felix-schwarz @TheOneRing Is it also possible to not have a share jail when there are no shares?

In the legacy WebDAV endpoint, the share jail is just a regular folder for the clients. So if there is no folder, there’s not a problem.

[felix-schwarz]

@felix-schwarz @TheOneRing Is it also possible to not have a share jail when there are no shares?

I don't see a problem with that at the moment. It just wouldn't show up in the drive/spaces list then.

[TheOneRing]

This issue is about the legacy endpoint, which might still be used after the ocis release, as we are not able to migrate all clients.
In order to mute the error, the legacy endpoint could provide a dummy etag if the mapped shares jail does not report any?

For the listing of drives, I'm pretty sure I can handle it in the client, so no need to modify anything there.

[micbar]

Fixed by cs3org/reva#2664