Report request for search responds with different href in new dav - tests need adjusting #3907

SwikritiT · 2022-06-01T11:48:23Z

Describe the bug

Report request for search responds with href in new dav

Steps to reproduce

Steps to reproduce the behavior:

As user einstein create folder test-one, test-two, test-three
Send search request for test in new dav

curl -X REPORT -vk -u einstein:relativity https://localhost:9200/remote.php/dav/files/einstein -d '<?xml version="1.0" encoding="UTF-8"?>
<oc:search-files
    xmlns:a="DAV:"
    xmlns:oc="http://owncloud.org/ns">
    <oc:search>
        <oc:pattern>test</oc:pattern>
    </oc:search>
</oc:search-files>'

Expected behavior

The href of response should be something like /remote.php/dav/files/einstein/test like in oc10

oc10 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>/core/remote.php/dav/files/admin/upload-one</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 01 Jun 2022 07:20:34 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>0</d:quota-used-bytes>
                <d:quota-available-bytes>-3</d:quota-available-bytes>
                <d:getetag>&quot;62971342efdb3&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/core/remote.php/dav/files/admin/upload-two</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 01 Jun 2022 07:20:42 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>0</d:quota-used-bytes>
                <d:quota-available-bytes>-3</d:quota-available-bytes>
                <d:getetag>&quot;6297134aaa989&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/core/remote.php/dav/files/admin/upload</d:href>
        <d:propstat>
            <d:prop>
                <d:getlastmodified>Wed, 01 Jun 2022 07:20:23 GMT</d:getlastmodified>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <d:quota-used-bytes>0</d:quota-used-bytes>
                <d:quota-available-bytes>-3</d:quota-available-bytes>
                <d:getetag>&quot;62971337ddfb9&quot;</d:getetag>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

Actual behavior

The href is that of spaces /dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51/test-one

ocis response

<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
    <d:response>
        <d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51/test-one</d:href>
        <d:propstat>
            <d:prop>
                <oc:fileid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!1d97967d-c763-45e6-8604-8d5291f6183c</oc:fileid>
                <d:getetag></d:getetag>
                <d:getlastmodified>2022-06-01T07:30:44Z</d:getlastmodified>
                <d:getcontenttype>httpd/unix-directory</d:getcontenttype>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <oc:score>0</oc:score>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51/test-two</d:href>
        <d:propstat>
            <d:prop>
                <oc:fileid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!1beed22b-31a4-4b18-9b0c-51732957e319</oc:fileid>
                <d:getetag></d:getetag>
                <d:getlastmodified>2022-06-01T07:30:50Z</d:getlastmodified>
                <d:getcontenttype>httpd/unix-directory</d:getcontenttype>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <oc:score>0</oc:score>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51/test-three</d:href>
        <d:propstat>
            <d:prop>
                <oc:fileid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!fbe52c1a-bf7f-4ca3-b589-9a4cae7d1b16</oc:fileid>
                <d:getetag></d:getetag>
                <d:getlastmodified>2022-06-01T07:30:56Z</d:getlastmodified>
                <d:getcontenttype>httpd/unix-directory</d:getcontenttype>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <oc:score>0</oc:score>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
    <d:response>
        <d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51/test-four</d:href>
        <d:propstat>
            <d:prop>
                <oc:fileid>1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b87c8dee-ac62-4573-b136-a67982a1961f</oc:fileid>
                <d:getetag></d:getetag>
                <d:getlastmodified>2022-06-01T07:31:02Z</d:getlastmodified>
                <d:getcontenttype>httpd/unix-directory</d:getcontenttype>
                <d:resourcetype>
                    <d:collection/>
                </d:resourcetype>
                <oc:size>0</oc:size>
                <oc:score>0</oc:score>
            </d:prop>
            <d:status>HTTP/1.1 200 OK</d:status>
        </d:propstat>
    </d:response>
</d:multistatus>

This request gives 405 in both old dav and spaces api

Setup

Please describe how you started the server and provide a list of relevant environment variables.

OCIS_VERSION=latest (commit 45522e4fea14a45a8600626c53df62621e3cafff)
BRANCH=master
STORAGE_FRONTEND_UPLOAD_DISABLE_TUS=false

Additional context

Add any other context about the problem here.

The text was updated successfully, but these errors were encountered:

micbar · 2022-06-01T12:35:25Z

@SwikritiT Which request is giving a 405 response code?

IMO the spaces urls in the search response are correct.

micbar · 2022-06-01T13:02:57Z

@SwikritiT @phil-davis This is a REPORT request. It is allowed to return different href locations. Unlike a PROPFIND, we cannot scope this REPORT to
https://localhost:9200/remote.php/dav/files/einstein

@butonic JFYI for final approval and closing.

phil-davis · 2022-06-01T13:08:08Z

@SwikritiT as Michael says, the href is an implementation-specific link to where the resource can be accessed. As long as the link actually works (operations to GET the resource content etc can be done) then all is fine.

Is the test suite expecting/checking for some format that has remote.php/dav/... ?

If so, then we need to adjust the test suite to not be so specific.

butonic · 2022-06-01T13:24:16Z

The difference between PROPFIND and REPORT is that REPORT can actually return any kind of document, it does not even need to return a 207 Multistatus response. The semantics should be formally defined by the report specification, which for our search-files and filter-files only exists in code. They do follow the PROPFIND semantics so clients can reuse a lot of their XML parsing logic.

The CARDDAV:addressbook-query report follows the same approach:

The format of this report is modeled on the PROPFIND method. The request and response bodies of the CARDDAV:addressbook-query report use XML elements that are also used by PROPFIND.

I hope this clarifies why we can return href properties pointing to other URLs than the requested one.

SwikritiT · 2022-06-02T04:25:25Z

@SwikritiT Which request is giving a 405 response code?

IMO the spaces urls in the search response are correct.

@micbar these request are giving me 405

curl -X REPORT -vk -u einstein:relativity https://localhost:9200/remote.php/webdav -d '<?xml version="1.0" encoding="UTF-8"?> 
<oc:search-files
    xmlns:a="DAV:"
    xmlns:oc="http://owncloud.org/ns">
    <oc:search>
        <oc:pattern>test</oc:pattern>
    </oc:search>
</oc:search-files>'

response

*   Trying 127.0.0.1:9200...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=Acme Corp; CN=OCIS
*  start date: Jun  2 04:01:27 2022 GMT
*  expire date: Jun  2 04:01:27 2023 GMT
*  issuer: O=Acme Corp; CN=OCIS
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'einstein'
> REPORT /remote.php/webdav HTTP/1.1
> Host: localhost:9200
> Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ==
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 203
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 203 out of 203 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate, value
< Content-Length: 0
< Content-Security-Policy: frame-ancestors 'none'
< Date: Thu, 02 Jun 2022 04:02:11 GMT
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Last-Modified: Thu, 02 Jun 2022 04:02:11 GMT
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Web-Version: 45522e4fe
< 
* Connection #0 to host localhost left intact

 curl -X REPORT -vk -u einstein:relativity https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51/ -d '<?xml version="1.0" encoding="UTF-8"?>
<oc:search-files
    xmlns:a="DAV:"
    xmlns:oc="http://owncloud.org/ns">
    <oc:search>
        <oc:pattern>test</oc:pattern>
    </oc:search>
</oc:search-files>'

response

*   Trying 127.0.0.1:9200...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=Acme Corp; CN=OCIS
*  start date: Jun  2 04:01:27 2022 GMT
*  expire date: Jun  2 04:01:27 2023 GMT
*  issuer: O=Acme Corp; CN=OCIS
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'einstein'
> REPORT /dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157c510ada-c86b-4815-8820-42cdf82c3d51 HTTP/1.1
> Host: localhost:9200
> Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ==
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 203
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 203 out of 203 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 405 Method Not Allowed
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate, value
< Content-Length: 0
< Content-Security-Policy: frame-ancestors 'none'
< Date: Thu, 02 Jun 2022 04:13:53 GMT
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Last-Modified: Thu, 02 Jun 2022 04:13:53 GMT
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Web-Version: 45522e4fe
< 
* Connection #0 to host localhost left intact

SwikritiT · 2022-06-02T04:26:51Z

@SwikritiT as Michael says, the href is an implementation-specific link to where the resource can be accessed. As long as the link actually works (operations to GET the resource content etc can be done) then all is fine.

Is the test suite expecting/checking for some format that has remote.php/dav/... ?

If so, then we need to adjust the test suite to not be so specific.

Yes we might need to adjust some tests related to search. They should pass in new dav but they're not. Will look into it.

SwikritiT · 2022-06-02T05:03:06Z

There are some tests in https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavOperations/search.feature that are currently in expected to fail but they should at least pass in new DAV path. Some adjustment is need probably here
https://github.com/owncloud/core/blob/7aa10a2d47a17eeb36c648a8c5d4e64f1655a059/tests/acceptance/features/bootstrap/WebDav.php#L5276-L5278

so that it doesn't expect only /remote.php/dav/.. and can be used for spaces as well.

TODO QA-team :

adjust the code [tests-only][full-ci]Adjust for new webdav for search request on OCIS core#40159
remove the passing test from expected to fail Expected to failure update for search request with REPORT method #4043

phil-davis · 2022-06-02T05:22:33Z

I adjusted the title so it is clear that tests need to be adjusted. Re-opening - this will be sorted out by QA Test Automation team.

SagarGi · 2022-06-21T09:08:47Z

@SwikritiT @kiranparajuli589 @phil-davis while searching on oc10, it is not case sensitive while ocis is case sensitive.
for eg this step :

When user "Alice" searches for "ol" using the WebDAV API

oc10 gives search result containing 4 entries as:

And the search result of user "Alice" should contain these entries:
      | /just-a-folder           |
      | /upload folder           |
      | /FOLDER                  |
      | /just-a-folder/lolol.txt |

while in ocis gives search result containing 3 entries as:

And the search result of user "Alice" should contain these entries:
      | /just-a-folder           |
      | /upload folder           |
      | /just-a-folder/lolol.txt |

SagarGi · 2022-06-21T09:10:48Z

@phil-davis @SwikritiT @kiranparajuli589 Also while running test, on ocis 1 sec is need to wait for the response to be set otherwise response is null

kiranparajuli589 · 2022-06-21T09:17:44Z

@SwikritiT @kiranparajuli589 @phil-davis while searching on oc10, it is not case sensitive while ocis is case sensitive.

maybe creating a new|separate ticket for this will be a lot clearer.

SagarGi · 2022-06-28T05:41:25Z

@SwikritiT every thing related to this issue has been done so far. this can be closed?

SwikritiT · 2022-06-28T10:50:11Z

@SwikritiT every thing related to this issue has been done so far. this can be closed?

If there aren't any expected to fail links to this issue in web, ocis, reva we can close this.

SwikritiT · 2022-06-29T04:45:32Z

No links to expected to fail. So closing

SwikritiT added the Type:Bug label Jun 1, 2022

micbar added Status:Needs-Revision Needs code input from a maintainer QA:team and removed Type:Bug labels Jun 1, 2022

butonic closed this as completed Jun 1, 2022

phil-davis changed the title ~~Report request for search responds with wrong href in new dav~~ Report request for search responds with different href in new dav - tests need adjusting Jun 2, 2022

phil-davis reopened this Jun 2, 2022

kiranparajuli589 mentioned this issue Jun 15, 2022

Update expected to fail file to use the correct issue for failing tests owncloud/web#7011

Closed

3 tasks

SagarGi self-assigned this Jun 20, 2022

SagarGi mentioned this issue Jun 21, 2022

[tests-only][full-ci]Adjust for new webdav for search request on OCIS owncloud/core#40159

Merged

11 tasks

SwikritiT closed this as completed Jun 29, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Report request for search responds with different href in new dav - tests need adjusting #3907

Report request for search responds with different href in new dav - tests need adjusting #3907

SwikritiT commented Jun 1, 2022 •

edited

Loading

micbar commented Jun 1, 2022

micbar commented Jun 1, 2022

phil-davis commented Jun 1, 2022

butonic commented Jun 1, 2022

SwikritiT commented Jun 2, 2022

SwikritiT commented Jun 2, 2022

SwikritiT commented Jun 2, 2022 •

edited by SagarGi

Loading

phil-davis commented Jun 2, 2022

SagarGi commented Jun 21, 2022

SagarGi commented Jun 21, 2022

kiranparajuli589 commented Jun 21, 2022 •

edited

Loading

SagarGi commented Jun 28, 2022

SwikritiT commented Jun 28, 2022

SwikritiT commented Jun 29, 2022

Report request for search responds with different href in new dav - tests need adjusting #3907

Report request for search responds with different href in new dav - tests need adjusting #3907

Comments

SwikritiT commented Jun 1, 2022 • edited Loading

Describe the bug

Steps to reproduce

Expected behavior

Actual behavior

Setup

Additional context

micbar commented Jun 1, 2022

micbar commented Jun 1, 2022

phil-davis commented Jun 1, 2022

butonic commented Jun 1, 2022

SwikritiT commented Jun 2, 2022

SwikritiT commented Jun 2, 2022

SwikritiT commented Jun 2, 2022 • edited by SagarGi Loading

phil-davis commented Jun 2, 2022

SagarGi commented Jun 21, 2022

SagarGi commented Jun 21, 2022

kiranparajuli589 commented Jun 21, 2022 • edited Loading

SagarGi commented Jun 28, 2022

SwikritiT commented Jun 28, 2022

SwikritiT commented Jun 29, 2022

SwikritiT commented Jun 1, 2022 •

edited

Loading

SwikritiT commented Jun 2, 2022 •

edited by SagarGi

Loading

kiranparajuli589 commented Jun 21, 2022 •

edited

Loading