merge ocdav into frontend #1958

butonic · 2025-12-02T15:00:43Z

This PR moves the ocdav handler back into the frontend. This removes one usage of the go micro service.

butonic · 2025-12-05T12:17:34Z

it seems reva handles a leading // differently:

  Scenario: send PROPFIND requests to webDav endpoints with 2 slashes using the spaces WebDAV API                                 # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature:155
    When user "Alice" requests these endpoints with "PROPFIND" to get property "d:href" about user "Alice"                        # AuthContext::theUserRequestsTheseEndpointsToGetOrSetPropertyAboutUser()
      | endpoint                                 |
      | //dav//spaces/%spaceid%/textfile1.txt    |
      | /dav//spaces/%spaceid%/PARENT/parent.txt |
      | /dav//spaces/%spaceid%/PARENT            |
      | //dav/spaces//%spaceid%//FOLDER          |
    Then the HTTP status code of responses on each endpoint should be "200,207,207,200" on OpenCloud or "207,207,207,207" on reva # FeatureContext::theHTTPStatusCodeOfResponsesOnEachEndpointShouldBeOcReva()
      Expected HTTP status codes: "200,207,207,200". Found HTTP status codes: "405,207,207,405"
      Failed asserting that false is true.

  Scenario: send PROPPATCH requests to webDav endpoints with 2 slashes                                                 # /woodpecker/src/github.com/opencloud-eu/opencloud/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature:165
    When user "Alice" requests these endpoints with "PROPPATCH" to set property "d:getlastmodified" about user "Alice" # AuthContext::theUserRequestsTheseEndpointsToGetOrSetPropertyAboutUser()
      | endpoint                                 |
      | //webdav/textfile0.txt                   |
      | //dav//files/%username%/textfile1.txt    |
      | /dav//files/%username%/PARENT/parent.txt |
      | /webdav//PARENT                          |
      | //dav//files/%username%//FOLDER          |
    Then the HTTP status code of responses on each endpoint should be "200,200,400,400,200" respectively               # FeatureContext::theHTTPStatusCodeOfResponsesOnEachEndpointShouldBe()
      Expected HTTP status codes: "200,200,400,400,200". Found HTTP status codes: "405,405,400,400,405"
      Failed asserting that false is true.

butonic · 2025-12-05T14:19:43Z

@ScharfViktor the tests were expecting the wrong status codes. I corrected them and CI should now become green.

aduffeck · 2025-12-08T10:16:00Z

services/frontend/pkg/config/config.go

 }

+type OCDav struct {
+	Prefix string `yaml:"prefix" env:"OCDAV_HTTP_PREFIX" desc:"A URL path prefix for the handler." introductionVersion:"1.0.0"`


Should we introduce FRONTEND_OCDAV_* variables and deprecate the OCDAV_* ones for consistency?

I would rather aim for dropping the service prefix. @rhafer proposed that and since we are deploying only one process in the compose stack and two or three in the helm chart, I agree. In this case OCDAV_ would match the handler, so I think reusing them is fine.

IIRC @dragonchaser is trying to reduce the number of env vars as well, so he might have an opinion as well.

Might be confusing when this is a service specific variable and there is no standalone ocdav-service anymore.
IMHO @aduffeck change would make sense

so, keep the old env var OCDAV_HTTP_PREFIX but allow overriding it with a more specific one?

Suggested change

Prefix string `yaml:"prefix" env:"OCDAV_HTTP_PREFIX" desc:"A URL path prefix for the handler." introductionVersion:"1.0.0"`

Prefix string `yaml:"prefix" env:"OCDAV_HTTP_PREFIX;FRONTEND_OCDAV_HTTP_PREFIX" desc:"A URL path prefix for the handler." introductionVersion:"1.0.0"`

For now, I'm fine with this as it would follow the pattern that we currently have. I wonder if we can then drop the FRONTEND_OCDAV_HTTP_PREFIX later ...

butonic · 2026-01-07T08:22:57Z

cc @ScharfViktor @saw-jan flaky run

runsh: Total unexpected failed scenarios throughout the test run:
apiCollaboration/wopi.feature:495

flaky run

runsh: Total unexpected failed scenarios throughout the test run:
apiSearchContent/extractedProps.feature:426

saw-jan · 2026-01-07T09:03:36Z

cc @ScharfViktor @saw-jan flaky run

runsh: Total unexpected failed scenarios throughout the test run:
apiCollaboration/wopi.feature:495

flaky run

runsh: Total unexpected failed scenarios throughout the test run:
apiSearchContent/extractedProps.feature:426

wopi API tests seem to be more flaky. I have created an issue for this #2110

butonic · 2026-01-07T13:08:25Z

cc @ScharfViktor @saw-jan flaky run

runsh: Total unexpected failed scenarios throughout the test run:
coreApiWebdavMove2/moveShareOnOpencloud.feature:283

ScharfViktor · 2026-01-07T13:14:46Z

cc @ScharfViktor @saw-jan flaky run

but how??

When user "Alice" moves folder "Shares/testshare/testfile.txt" to "Shares/testshare/child/testfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/Shares/testshare/child/testfile.txt" should exist -> ✅️ file is moved
And as "Brian" file "/testshare/child/testfile.txt" should exist
And as "Alice" file "/Shares/testshare/testfile.txt" should not exist -> It turns out that we have the file both here and there.

I see that file is exist but we moved it in line

### And as "Alice" file "/Shares/testshare/testfile.txt" should not exist
		_______________________________________________________________________

		==> REQUEST
		PROPFIND /remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/testshare/testfile.txt
		X-Request-ID: coreApiWebdavMove2/moveShareOnOpencloud.feature:283-275
		==> REQ BODY
		<?xml version="1.0"?>
				<d:propfind
				   xmlns:d="DAV:"
				   xmlns:oc="[http://owncloud.org/ns"](http://owncloud.org/ns%22)
				   xmlns:ocs="[http://open-collaboration-services.org/ns"](http://open-collaboration-services.org/ns%22)
				   >
				    <d:prop><d:getetag/><d:resourcetype/></d:prop>
				</d:propfind>

		<== RESPONSE
		207 Multi-Status
		X-Xss-Protection: 1; mode=block
		<== RES BODY
		<d:multistatus xmlns:s="[http://sabredav.org/ns"](http://sabredav.org/ns%22) xmlns:d="DAV:" xmlns:oc="[http://owncloud.org/ns"><d:response><d:href>/remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/testshare/testfile.txt</d:href><d:propstat><d:prop><d:getetag>"d86b0cd3c4b5d8e5b8c0eb91a7a24bf4"</d:getetag><d:resourcetype></d:resourcetype></d:prop><d:status>HTTP/1.1](http://owncloud.org/ns%22%3E%3Cd:response%3E%3Cd:href%3E/remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/testshare/testfile.txt%3C/d:href%3E%3Cd:propstat%3E%3Cd:prop%3E%3Cd:getetag%3E%22d86b0cd3c4b5d8e5b8c0eb91a7a24bf4%22%3C/d:getetag%3E%3Cd:resourcetype%3E%3C/d:resourcetype%3E%3C/d:prop%3E%3Cd:status%3EHTTP/1.1) 200 OK</d:status></d:propstat></d:response></d:multistatus>

butonic · 2026-01-07T14:02:54Z

cc @ScharfViktor @saw-jan flaky run

runsh: Total unexpected failed scenarios throughout the test run:
apiSharingNgLinkSharePermission/createLinkShare.feature:806

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic · 2026-01-07T14:05:12Z

I rebased on master to get #2099

butonic requested a review from rhafer December 2, 2025 15:00

butonic self-assigned this Dec 2, 2025

butonic added this to OpenCloud Team Board Dec 2, 2025

butonic added Type:Maintenance E.g. technical debt, packaging, etc. Type:Breaking-Change labels Dec 2, 2025

github-project-automation bot moved this to Qualification in OpenCloud Team Board Dec 2, 2025

butonic force-pushed the ocdav-to-frontent branch 6 times, most recently from a9f558d to 0947bf7 Compare December 5, 2025 09:39

butonic force-pushed the ocdav-to-frontent branch from 153516d to 2345e74 Compare December 5, 2025 15:11

butonic moved this from Qualification to In Progress in OpenCloud Team Board Dec 5, 2025

butonic requested a review from aduffeck December 8, 2025 09:48

aduffeck approved these changes Dec 8, 2025

View reviewed changes

butonic mentioned this pull request Dec 11, 2025

[Bug] Invalid Memory in antivirus container - nil pointer dereference #1998

Closed

butonic force-pushed the ocdav-to-frontent branch from a456971 to afb8cbe Compare December 12, 2025 10:25

butonic mentioned this pull request Dec 15, 2025

flaky API tests opencloud-eu/qa#50

Closed

butonic force-pushed the ocdav-to-frontent branch 2 times, most recently from 3099fb1 to 7f19839 Compare December 16, 2025 09:09

butonic force-pushed the ocdav-to-frontent branch from 7f19839 to e09b6d3 Compare January 6, 2026 08:41

merge ocdav into frontend

c993423

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic added 5 commits January 7, 2026 15:04

use clean urls for routing

38eb7fb

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

update tests to expect correct status codes

5fc0186

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

correctly handle paths ending in /

84dce9a

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

read edition directly from version, enable name validation config

b258cbb

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

use FRONTEND_ env prefix as well

36f9d38

Signed-off-by: Jörn Friedrich Dreyer <jfd@butonic.de>

butonic force-pushed the ocdav-to-frontent branch from 218a050 to 36f9d38 Compare January 7, 2026 14:04

dragonchaser approved these changes Jan 7, 2026

View reviewed changes

butonic merged commit 4c600d8 into main Jan 7, 2026
60 checks passed

butonic deleted the ocdav-to-frontent branch January 7, 2026 16:17

github-project-automation bot moved this from In Progress to Done in OpenCloud Team Board Jan 7, 2026

openclouders mentioned this pull request Jan 7, 2026

🎉 Release 5.0.0 #2035

Open

1 task

	Prefix string `yaml:"prefix" env:"OCDAV_HTTP_PREFIX" desc:"A URL path prefix for the handler." introductionVersion:"1.0.0"`
	Prefix string `yaml:"prefix" env:"OCDAV_HTTP_PREFIX;FRONTEND_OCDAV_HTTP_PREFIX" desc:"A URL path prefix for the handler." introductionVersion:"1.0.0"`

merge ocdav into frontend #1958

merge ocdav into frontend #1958

Uh oh!

Conversation

butonic commented Dec 2, 2025

Uh oh!

butonic commented Dec 5, 2025

Uh oh!

butonic commented Dec 5, 2025

Uh oh!

aduffeck Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

butonic Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dragonchaser Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

butonic Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

butonic commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saw-jan commented Jan 7, 2026

Uh oh!

butonic commented Jan 7, 2026

Uh oh!

ScharfViktor commented Jan 7, 2026

Uh oh!

butonic commented Jan 7, 2026

Uh oh!

butonic commented Jan 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

butonic Dec 8, 2025 •

edited

Loading

butonic commented Jan 7, 2026 •

edited

Loading