Different propfind response compared with core

[haribhandari07]

Description

Core

Request:

curl -X PROPFIND http://localhost/core1/remote.php/dav/files/admin/welcome.txt -u admin:admin | xmllint --format -

Response:

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/core1/remote.php/dav/files/admin/welcome.txt</d:href>
    <d:propstat>
      <d:prop>
        <d:getlastmodified>Thu, 30 Apr 2020 04:51:34 GMT</d:getlastmodified>
        <d:getcontentlength>163</d:getcontentlength>
        <d:resourcetype/>
        <d:getetag>"0714d06070cb5e04b496a46c5336a19a"</d:getetag>
        <d:getcontenttype>text/plain</d:getcontenttype>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

ocis

Request: curl -s -u user0:123456 -X PROPFIND http://localhost:9140/remote.php/webdav/hari.txt | xmllint --format -

Response:

<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/remote.php/webdav/hari.txt</d:href>
    <d:propstat>
      <d:prop>
        <oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTYyOmNjNDhhZjBmLTdkNTAtNGU5Ni1hY2VmLTgxNWVhM2FjZmU3Mg==</oc:id>
        <oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTYyOmNjNDhhZjBmLTdkNTAtNGU5Ni1hY2VmLTgxNWVhM2FjZmU3Mg==</oc:fileid>
        <d:getetag>"9bd9f3c40e1ccecacc7c1dcc8328979a"</d:getetag>
        <oc:permissions>WCKDNVR</oc:permissions>
        <d:getcontentlength>14</d:getcontentlength>
        <d:getcontenttype>text/plain; charset=utf-8</d:getcontenttype>
        <d:getlastmodified>Tue, 02 Jun 2020 04:17:56 UTC</d:getlastmodified>
        <oc:favorite>0</oc:favorite>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

As you can see, we don't get oc:permissions in response for core

[PVince81]

can you add a test for it ?

[PVince81]

looks like the attributes that are returned by default are not the same ones in OCIS than OC 10.

minor issue I think, unless it breaks many existing tests

[dpakach]

Breaks many tests because the format of the properties is different than that in core

• d:getlastmodified is in format Fri, 09 Oct 2020 11:02:09 +0000 as opposed to Wed, 30 Sep 2020 13:53:16 GMT in oc10

• d:contenttype for folder is httpd/unix-directory as opposed to empty in oc10

• oc:size has value 4096 by default for empty folders whereas its 0 in oc10.

• oc:fileid is alphanumeric as opposed to numeric in oc10

• oc:owner-display-name is empty as opposed to display name of owner in oc10

• oc:permissions is not formatted correctly. for eg WCKDNVR in OCIS vs. RDNVW in oc10

[phil-davis]

For some of that stuff we need to make the tests more flexible.

• d:getlastmodified sort out what date-time formats are acceptable, and match any of those
• d:contenttype of httpd/unix-directory is probably "a good thing" - sort out if clients can cope with this, and if oC10 should also work like that
• oc:fileid the tests should be more flexible. I don't think there is any spec that says the file id must numeric.
• oc:permissions could have the letters in any order (and then think about what other flexibility is appropriate)

[C0rby]

There are two lines in the expecated failures file:

-   [apiWebdavProperties2/getFileProperties.feature:327](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavProperties2/getFileProperties.feature#L327)
-   [apiWebdavProperties2/getFileProperties.feature:328](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavProperties2/getFileProperties.feature#L328)

They fail because oCIS returns "text/plain; charset=utf-8" in the getcontenttype attribute. This value is valid according to the webdav spec.

@phil-davis, can the test be adjusted to also accept mime types with parameters?

[phil-davis]

can the test be adjusted to also accept mime types with parameters?

Is the rule just that the expected value starts with text/plain ?
i.e. it can have "anything" in the parameters (I won't try to parse and check that the parameters "look valid")

or I can check that the response contains either exactly text/plain or text/plain; charset=utf-8

[phil-davis]

owncloud/core#39045

It is easy to check for a string starting with text/plain. The test step already supports a regex.