WebDAV is fetched twice on initial page load

[juliusknorr]

Steps to reproduce

• Load the files app through /apps/files
• Observe the network requests

Current behaviour

The PROPFIND on the root directory is sent twice

Actual behaviour

Only one request should be done

Additional context

Reproducible on 29.0.2 and latest master

@nextcloud/server-frontend

[juliusknorr]

Same is actually the case when going to the recents view and reloading the page

[skjnldsv]

server/apps/files/src/views/FilesList.vue

Lines 480 to 481 in 1d7893d

	// reload on settings change
	this.unsubscribeStoreCallback = this.userConfigStore.$subscribe(() => this.fetchContent(), { deep: true })

Coming from here @susnux

[susnux]

Probably it triggers a settings change directly on init?
Or the view is loaded before the settings?

[skjnldsv]

Or the view is loaded before the settings?

probably that

[juliusknorr]

It seems things got worse, so maybe worth to schedule looking into this @sorbaugh

just noticed on my local instance it is doing 4 propfinds against the root on a page load, same on our prod.

[skjnldsv]

On it

[susnux]

I think the reason why it is increasing is that there is no other way for other apps to load the current content.

Meaning if you need the current content of the files app, you have to use view::getContent there is no way to get a cached version of the current content.
So if we do not want to introduce new API, we could just extend the current by adjusting View::getContents to have a parameter force = true (most secure backwards compatibility).

This would not need any adjustments of using apps, as the ViewData could stay as it is (so the View constructor call), but we just need to adjust the View class to cache the returned value for a given path and only call the ViewData::getContents when force is set.

[skjnldsv]

Yes and no, there are various issues:

1. the filter indeed gets their own contents
2. The Filelist monitors any userConfig store changes, so it gets triggered again on initial populating
3. The uploader fetch its own content on init too

I'll address 2 and 3 in a minute, still thinking about 1

Basically there was 2 content fetched, and #45708 added 2 more

[skjnldsv]

3 is fixed by nextcloud-libraries/nextcloud-upload#1313

• chore: 1.4.3 nextcloud-libraries/nextcloud-upload#1322

[susnux]

Nice fixes :)

But I still think we need a way to access the current content without require to refetch, this was possible in legacy file list, but now the only option is view.getContents which is not cached.
Not only for us here but also potentially for other apps that hook into files API.

[skjnldsv]

@susnux what about an etag on root, or a similar approach?
Then a very tiny request would be easy to know if we're out of date?

[skjnldsv]

Let's re-open for the filter issue

server/apps/files_sharing/src/components/FileListFilterAccount.vue

Line 118 in 77cffcb

const { contents } = await currentView.value.getContents(path)

[susnux]

Then a very tiny request would be easy to know if we're out of date?

Yes for some parts this would be quite a nice improvement.
But it does not solve this issue, as it would still cause a full request, as we do not know any node.

Also if there are more apps, this issue will grow as each app needs to request the etag.

So we could do both, use the etag and allow getting a cached version.

[provokateurin]

Photos app has the same problem btw, not sure if that will be fixed automatically if it is fixes for Files.

[solracsf]

I don't know if this is related, but many (8 out of 10) PROPFIND requests seen by nginx are doubled, the first being aborted "by the client" (code 499):

PROPFIND /remote.php/dav/files/user/folder/ http_code=499
PROPFIND /remote.php/dav/files/user/folder/ http_code=207

v28.0.9, no sync/webdav clients involved (100% web).