Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Doesn't work with Infuse App #316

Open
Wamy-Dev opened this issue Mar 6, 2024 · 11 comments
Open

Doesn't work with Infuse App #316

Wamy-Dev opened this issue Mar 6, 2024 · 11 comments
Labels
bug

Comments

@Wamy-Dev
Copy link

Wamy-Dev commented Mar 6, 2024

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 Wamy-Dev added the bug label Mar 6, 2024
@Wamy-Dev
Copy link
Author

Wamy-Dev commented Mar 6, 2024

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

@mar10
Copy link
Owner

mar10 commented Mar 7, 2024

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)

@Wamy-Dev
Copy link
Author

Wamy-Dev commented Mar 7, 2024 

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 Wamy-Dev changed the title Doesn't work with Infuse App Doesn't work with Rclone Mount Mar 7, 2024
@Wamy-Dev
Copy link
Author

Wamy-Dev commented Mar 7, 2024

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

@Wamy-Dev
Copy link
Author

Wamy-Dev commented Mar 7, 2024

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
Copy link
Author

Wamy-Dev commented Mar 7, 2024 •
edited by mar10
Loading

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 Wamy-Dev changed the title Doesn't work with Rclone Mount Doesn't work with Infuse App Mar 7, 2024
@Wamy-Dev Wamy-Dev closed this as completed Mar 7, 2024
@Wamy-Dev Wamy-Dev reopened this Mar 7, 2024
@rahaaatul
Copy link

rahaaatul commented Aug 3, 2024 •
edited
Loading

@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.

@Wamy-Dev
Copy link
Author

Wamy-Dev commented Aug 3, 2024 •
edited
Loading

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.

@rahaaatul
Copy link

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.

@Wamy-Dev Wamy-Dev reopened this Oct 8, 2024
@Wamy-Dev
Copy link
Author

Wamy-Dev commented Oct 8, 2024

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
Copy link
Author

Wamy-Dev commented Oct 8, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mar10 @Wamy-Dev @rahaaatul