wsgidav icon indicating copy to clipboard operation
wsgidav copied to clipboard
verified publisher icon mar10

Doesn't work with Infuse App

Open Wamy-Dev opened this issue 1 year ago • 11 comments

Describe the bug

When hosting a webdav using wsgidav, and connecting using the Infuse app (Mac or iOS), it sends a propfind to /, with a depth of 1. This returns the folders properly, but they are seen as files on Infuse. I have tried other webdavs with Infuse and they all work fine. The folders are seen as files.

To Reproduce

Host webdav Add to Infuse Connect on Infuse

Expected behavior

Being able to navigate folders to files.

Which WSGI server was used (cheroot, ext-wsgiutils, gevent, gunicorn, paste, uvicorn, wsgiref, ...)?

Any, though tested with cheroot and uvicorn.

Which WebDAV client was used (MS File Explorer, MS Office, macOS Finder, WinSCP, Windows, file mapping, ...)?

Infuse (sees folders as files), Finder (works fine), Windows (works fine), Linux (works fine)

Wamy-Dev avatar Mar 06 '24 20:03 Wamy-Dev

I have already contacted Infuse, they basically told me that they cannot fix it.

Wamy-Dev avatar Mar 06 '24 20:03 Wamy-Dev

Hi, please reproduce the problem while running the client in verbose mode (-vv) and share the logs (make sure to not include sensitive data like credentials)

mar10 avatar Mar 07 '24 16:03 mar10 

16:24:16.136 - INFO    : Got OPTIONS '/' request
16:24:16.648 - INFO    : 100.107.73.41 - (anonymous) - [2024-03-07 22:24:16] "PROPFIND /" length=153, depth=1, elap=0.512sec -> 207 Multi-Status

It seems to only fail when I am using files from Rclone mount. I guess I never tested with local files. I am going to try figuring out about the permissions.

Wamy-Dev avatar Mar 07 '24 22:03 Wamy-Dev

This is a weird issue. Sending a PROPFIND request using an http tester (postman, insomnia) just never yields a response.

Wamy-Dev avatar Mar 07 '24 22:03 Wamy-Dev

Here's some more information. For a large directory (with over 100k files in total), it seems like the propfind just takes FOREVER. I waited about 10 minutes and it was still loading.

Wamy-Dev avatar Mar 07 '24 22:03 Wamy-Dev

I'm slowly figuring things out, when using a smaller directory, it loads fast, but this is the response:

<?xml version='1.0' encoding='UTF-8'?>
<D:multistatus
	xmlns:D="DAV:">
	<D:response>
		<D:href>/</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype>
					<D:collection/>
				</D:resourcetype>
				<D:creationdate>2024-02-18T16:58:38Z</D:creationdate>
				<D:quota-used-bytes>0</D:quota-used-bytes>
				<D:quota-available-bytes>1125899906842624</D:quota-available-bytes>
				<D:getlastmodified>Sun, 18 Feb 2024 16:58:38 GMT</D:getlastmodified>
				<D:displayname>0a3a8b769669be92dc6b6433fdf3d61df142b437</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/XXXFOLDERXXX/</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype>
					<D:collection/>
				</D:resourcetype>
				<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
				<D:quota-used-bytes>0</D:quota-used-bytes>
				<D:quota-available-bytes>1125899906842624</D:quota-available-bytes>
				<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
				<D:displayname>XXXFOLDERXXX</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/XXXFOLDERXXX/XXXITEMXXX.mkv</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype></D:resourcetype>
				<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
				<D:getcontentlength>30931047</D:getcontentlength>
				<D:getcontenttype>video/x-matroska</D:getcontenttype>
				<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
				<D:displayname>XXXITEMXXX.mkv</D:displayname>
				<D:getetag>11658933646639649267-1708189172-30931047</D:getetag>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/XXXFOLDERXXX/XXXITEMXXX.mkv</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype></D:resourcetype>
				<D:creationdate>2024-02-17T16:59:32Z</D:creationdate>
				<D:getcontentlength>5077136691</D:getcontentlength>
				<D:getcontenttype>video/x-matroska</D:getcontenttype>
				<D:getlastmodified>Sat, 17 Feb 2024 16:59:32 GMT</D:getlastmodified>
				<D:displayname>XXXITEMXXX.mkv</D:displayname>
				<D:getetag>10955713599619190573-1708189172-5077136691</D:getetag>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
</D:multistatus>

What Infuse shows is simply:

XXXFOLDERXXX

It doesn't show anything deeper. The request that was received from Infuse is this:

16:59:06.167 - INFO : 100.107.73.41 - (anonymous) - [2024-03-07 22:59:06] "PROPFIND /" length=153, depth=1, elap=0.001sec -> 207 Multi-Status

While the request from Insomnia (http tester) was:

16:58:54.255 - INFO : 127.0.0.1 - (anonymous) - [2024-03-07 22:58:54] "PROPFIND /" depth=infinity, agent="insomnia/2023.5.8", elap=0.003sec -> 207 Multi-Status

It seems like this is an Infuse issue more and more. I tested with some local file directories that had video inside, and it seems like Infuse simply does not dive into directories at all. I'm gonna close this, sorry for my rambling. Seems like it is an Infuse issue as I suspected. I will see if their forums will be a little more helpful. If you have any more insight on how I can force Infuse to use a depth of infinity instead, please let me know.

Wamy-Dev avatar Mar 07 '24 23:03 Wamy-Dev

@Wamy-Dev can you test wsgidav with Kodi, please? Kodi fails to scan files when I'm using basic/digest authentication, but works with anonymous. I tried with another WebDAV server, Kodi works with authentication just fine.

Kodi says:

2024-08-03 14:48:53.274 T:5212    error <general>: CCurlFile::XFILE::CCurlFile::Stat - <dav://USERNAME:[email protected]:8080/Download/Videos/Movies/Leo%20(2023)/> Failed: Unsupported protocol(1)

WSGIDAV says:

14:48:55.647 - INFO    : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "HEAD /Download/Videos/Movies/Leo (2023)/" elap=0.001sec -> 401 Not Authorized                                             
14:48:55.659 - INFO    : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.001sec -> 401 Not Authorized                
14:48:55.661 - INFO    : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "HEAD /Download/Videos/Movies/Leo (2023)/" elap=0.006sec -> 200 OK               
14:48:55.688 - INFO    : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.020sec -> 207 Multi-Status                          
14:48:55.701 - INFO    : 192.168.1.100 - (anonymous) - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.001sec -> 401 Not Authorized                
14:48:55.729 - INFO    : 192.168.1.100 - RGX - [2024-08-03 08:48:55] "PROPFIND /Download/Videos/Movies/Leo (2023)/" depth=1, range=bytes=0-, elap=0.016sec -> 207 Multi-Status

Can you please test it for me? I'm kind of a newb in this and I need some help from someone.

rahaaatul avatar Aug 03 '24 08:08 rahaaatul

Yeah, Kodi was one that I tested before, you need to make sure you use "dav://username:password@hostname:port" or "davs://username:[email protected]" (If SSL protected).

You can't use HTTP(S) cause then it just uses the website, which works entirely differently.

I know your log says that you are using dav, but other than that, make sure the auth is 100% correct.

Wamy-Dev avatar Aug 03 '24 15:08 Wamy-Dev

Yeah, Kodi was one that I tested before, you need to make sure you use "dav://username:password@hostname:port" or "davs://username:[email protected]" (If SSL protected).

You can't use HTTP(S) cause then it just uses the website, which works entirely differently.

I know your log says that you are using dav, but other than that, make sure the auth is 100% correct.

The auth is correct, I can browse my media files in Kodi. It's only when I'm scraping. And I don't understand why, but I narrowed it down to a server issue. Because I tried with another DAV server, hosted in mixplorer with same credentials, and the unsupported protocol issue was nonexistent.

Will you be able to check one more time, if it works for you?

If it works without the unsupported protocol issue, can you share your .yaml config file with me, please? I'm using the sample_wsgidav.yaml and modified username, password, and folder paths. And everything else is untouched.

rahaaatul avatar Aug 03 '24 22:08 rahaaatul

I am having to reopen this due to folders not working properly with Infuse. After some updates and deeper testing I am not exactly sure what is the issue. First is a working webdav from rclone, rclone serve webdav which works perfectly in Infuse and other iOS clients.

In this propfind, with the header, Depth=1 (which Infuse sends), there is one folder and one file.

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus
	xmlns:D="DAV:">
	<D:response>
		<D:href>/</D:href>
		<D:propstat>
			<D:prop>
				<D:supportedlock>
					<D:lockentry
						xmlns:D="DAV:">
						<D:lockscope>
							<D:exclusive/>
						</D:lockscope>
						<D:locktype>
							<D:write/>
						</D:locktype>
					</D:lockentry>
				</D:supportedlock>
				<D:resourcetype>
					<D:collection
						xmlns:D="DAV:"/>
					</D:resourcetype>
					<D:displayname></D:displayname>
					<D:getlastmodified>Tue, 08 Oct 2024 01:37:16 GMT</D:getlastmodified>
					<D:lastmodified>1728351436</D:lastmodified>
				</D:prop>
				<D:status>HTTP/1.1 200 OK</D:status>
			</D:propstat>
		</D:response>
		<D:response>
			<D:href>/test.zip</D:href>
			<D:propstat>
				<D:prop>
					<D:resourcetype></D:resourcetype>
					<D:getetag>"17f619129af0662f5ab0"</D:getetag>
					<D:supportedlock>
						<D:lockentry
							xmlns:D="DAV:">
							<D:lockscope>
								<D:exclusive/>
							</D:lockscope>
							<D:locktype>
								<D:write/>
							</D:locktype>
						</D:lockentry>
					</D:supportedlock>
					<D:displayname>test.zip</D:displayname>
					<D:getcontentlength>23216</D:getcontentlength>
					<D:getlastmodified>Tue, 17 Sep 2024 17:44:34 GMT</D:getlastmodified>
					<D:getcontenttype>application/zip</D:getcontenttype>
					<D:lastmodified>1726595074</D:lastmodified>
				</D:prop>
				<D:status>HTTP/1.1 200 OK</D:status>
			</D:propstat>
		</D:response>
		<D:response>
			<D:href>/test%20folder/</D:href>
			<D:propstat>
				<D:prop>
					<D:displayname>test folder</D:displayname>
					<D:getlastmodified>Tue, 08 Oct 2024 01:36:56 GMT</D:getlastmodified>
					<D:resourcetype>
						<D:collection
							xmlns:D="DAV:"/>
						</D:resourcetype>
						<D:supportedlock>
							<D:lockentry
								xmlns:D="DAV:">
								<D:lockscope>
									<D:exclusive/>
								</D:lockscope>
								<D:locktype>
									<D:write/>
								</D:locktype>
							</D:lockentry>
						</D:supportedlock>
						<D:lastmodified>1728351416</D:lastmodified>
					</D:prop>
					<D:status>HTTP/1.1 200 OK</D:status>
				</D:propstat>
			</D:response>
		</D:multistatus>

Next is the response from WSGIDav. Some things I noticed about this is:

  1. If I enable lock_storage (not enabled here), it still doesn't work.
  2. Collections don't have the same, xmlns:D="DAV:". I tried adding this myself, but the nsmap never picks it up. I also try adding the xmlns="DAV:" attribute, but that also doesn't work, it just shows exactly xmlns="DAV:" without the D namespace. I'm not sure if this affects anything, but Infuse still doesn't seem to pick it up without it.
  3. Every response item is missing the <D:lastmodified> item.
  4. It might have to do with the locking, but I honestly doubt it, since it is just writing but may be something to look at.

In all I would recommend trying to replicate what Rclone has done as it works very well. Below are 2 folders, which Infuse should be able to open if correct (it doesn't)

<?xml version='1.0' encoding='UTF-8'?>
<D:multistatus
	xmlns:D="DAV:">
	<D:response>
		<D:href>/</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype>
					<D:collection/>
				</D:resourcetype>
				<D:getlastmodified>Tue, 08 Oct 2024 22:51:41 GMT</D:getlastmodified>
				<D:displayname></D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/Test%20Folder1/</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype>
					<D:collection/>
				</D:resourcetype>
				<D:getlastmodified>Tue, 08 Oct 2024 22:51:41 GMT</D:getlastmodified>
				<D:displayname>Test Folder1</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/Test%20Folder2/</D:href>
		<D:propstat>
			<D:prop>
				<D:resourcetype>
					<D:collection/>
				</D:resourcetype>
				<D:getlastmodified>Tue, 08 Oct 2024 22:51:41 GMT</D:getlastmodified>
				<D:displayname>Test Folder2</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
</D:multistatus>

Would really love some help on this, spent over 3 hours this morning trying to figure it out, so finally finding some help on the matter.

Wamy-Dev avatar Oct 08 '24 23:10 Wamy-Dev

While it may be an iOS client peculiarity, it should still be something to consider, thanks @mar10

Wamy-Dev avatar Oct 08 '24 23:10 Wamy-Dev

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jan 07 '25 20:01 github-actions[bot]