Fix cors

[micbar]

Description

CORS headers were not working correctly in WebDAV requests.

Problem

Somebody added custom cors handlers which overwrote the CORS middleware.

Bugfix: CORS handling for WebDAV requests fixed

We now correctly handle CORS headers for WebDAV requests.

#4461
owncloud/ocis#8231

Before

Access-Control-Allow-Origin: *

After

curl -L -X PROPFIND 'https://localhost:9200/dav/spaces/storage-users-1%24some-admin-user-id-0000-000000000000/' -k -i \
-H 'Origin: https://localhost:8080' \
-H 'Access-Control-Request-Method: PROPFIND' \
-H 'Depth: 1' \
-H 'Content-Type: application/xml' \
-H 'Authorization: Basic YWRtaW46YWRtaW4=' \
-d '<?xml version="1.0"?>
<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">
  <d:prop>
    <oc:permissions />
    <oc:favorite />
    <oc:fileid />
    <oc:owner-id />
    <oc:owner-display-name />
    <oc:share-types />
    <oc:privatelink />
    <d:getcontentlength />
    <oc:size />
    <d:getlastmodified />
    <d:getetag />
    <d:getcontenttype />
    <d:resourcetype />
    <oc:downloadURL />
  </d:prop>
</d:propfind>'
HTTP/1.1 207 Multi-Status
Access-Control-Allow-Origin: https://localhost:8080
Access-Control-Expose-Headers: Location, Tus-Resumable, Tus-Version, Tus-Extension
Content-Security-Policy: default-src 'none';
Content-Type: application/xml; charset=utf-8
Date: Mon, 22 Jan 2024 17:05:25 GMT
Dav: 1, 3, extended-mkcol
Tus-Extension: creation, creation-with-upload, checksum, expiration
Tus-Resumable: 1.0.0
Tus-Version: 1.0.0
Vary: Origin, Prefer
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: workbook/BbPn4czVfa-000003
X-Robots-Tag: none
X-Xss-Protection: 1; mode=block
Transfer-Encoding: chunked

[butonic]

@micbar #4460 is a reva pr for the master readme ... I doubt it is related ...

[micbar]

Scenario Outline: download a file with multipart ranges                                                                              # /drone/src/tmp/testrunner/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature:161
    Given using <dav-path-version> DAV path                                                                                            # FeatureContext::usingOldOrNewDavPath()
    When user "Alice" downloads file "/welcome.txt" with range "bytes=0-6, 40-51" using the WebDAV API                                 # FeatureContext::userDownloadsFileWithRangeUsingWebDavApi()
    Then the HTTP status code should be "206" or "200"                                                                                 # FeatureContext::theHTTPStatusCodeShouldBeOr()
    And if the HTTP status code was "206" then the following headers should match these regular expressions                            # FeatureContext::statusCodeShouldMatchTheseRegularExpressions()
      | Content-Length | /\d+/                                               |
      | Content-Type   | /^multipart\/byteranges; boundary=[a-zA-Z0-9_.-]*$/ |
    And if the HTTP status code was "206" then the downloaded content for multipart byterange should be:                               # FeatureContext::theDownloadedContentForMultipartByteRangeShouldBe()
      """
      Content-type: text/plain;charset=UTF-8
      Content-range: bytes 0-6/52
      
      Welcome
      
      Content-type: text/plain;charset=UTF-8
      Content-range: bytes 40-51/52
      
      developers.
      """
    But if the HTTP status code was "200" then the downloaded content should be "Welcome this is just an example file for developers." # FeatureContext::checkStatusCodeForDownloadedContentShouldBe()

    Examples:
      | dav-path-version |
      | old              |
        Failed step: And if the HTTP status code was "206" then the following headers should match these regular expressions
        '/^multipart\/byteranges; boundary=[a-zA-Z0-9_.-]*$/' does not match 'text/plain'
        Failed asserting that false is not false.
      | new              |
        Failed step: And if the HTTP status code was "206" then the following headers should match these regular expressions
        '/^multipart\/byteranges; boundary=[a-zA-Z0-9_.-]*$/' does not match 'text/plain'
        Failed asserting that false is not false.
      | spaces           |
        Failed step: And if the HTTP status code was "206" then the following headers should match these regular expressions
        '/^multipart\/byteranges; boundary=[a-zA-Z0-9_.-]*$/' does not match 'text/plain'
        Failed asserting that false is not false.

Mhh, i somehow destroyed the multipart headers for GET requests.

[micbar]

@rhafer I made the PR smaller, general middleware improvements are not bugfixes.