Lighttpd

Please provide more details, both client-side and server-side logs.
Try with lighttpd.conf webdav.log-xml = "enable" to add more trace to server-side logs.

lighttpd passes litmus tests for WebDAV compliance. See mod_webdav litmus tests and #1818

Please provide more details on your setup, including how lighttpd has been configured and how you are accessing it.

Hi, thanks for looking into it. My lighttpd.conf is here https://paste.gnome.org/pw44kaw0o . I am accessing webdav via Nemo/Nautilus. I was checking permissions but www:www and root:wheel do not help for lighttpd but rclone works fine with these permissions. Lightttpd binary has root:wheel permissions on Xigmanas 12.1.0.4.
Log shows this only and i think it is talking about the browser site:
Nov 29 01:06:01 xigmanas lighttpd: (mod_webdav.c.3430) XML-request-body: \n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:resourcetype/>\n<D:getcontentlength/>\n </D:prop>\n </D:propfind>
Nov 29 01:06:01 xigmanas lighttpd: (mod_webdav.c.3922) XML-response-body: \n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/webdav/</D:href>\n<D:propstat>\n<D:prop>\n<D:resourcetype><D:collection/></D:resourcetype><D:getcontentlength>57</D:getcontentlength></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n

lighttpd 1.4.55 webdav does not work with Nemo, Nautilus

That remains a broad statement without any details. Do you have any further details that you can provide? When does it fail? How does it fail? What actions do you take before it fails?

Your lighttpd.conf looks fine, as does the webdav multistatus response above. Perhaps Nemo, Nautilus are not expecting a webdav multistatus response?
(Your webdav.sqlite-db-name being in /tmp is a bit strange, but it looks intentional)

Here's a patch for unhandled live properties.

diff --git a/src/mod_webdav.c b/src/mod_webdav.c
index a2b3592e..986d3197 100644
--- a/src/mod_webdav.c
+++ b/src/mod_webdav.c
@@ -4040,6 +4040,8 @@ mod_webdav_propfind (request_st * const r, const plugin_config * const pconf)
                         ++list;
                     if (NULL != list->prop) {
                         if (cmd->name[0] == 'p') { /* "prop", not "include" */
+                            pb.proplist.ptr[pb.proplist.used].ns = "";
+                            pb.proplist.ptr[pb.proplist.used].nslen = 0;
                             pb.proplist.ptr[pb.proplist.used].name = NULL;
                             pb.proplist.ptr[pb.proplist.used].namelen =
                               list->pnum;

BTW, it is best to leave server.event-handler commented out (or absent) from lighttpd.conf in order to let lighttpd pick the best event handler for each system (kqueue on *BSD, epoll on Linux, etc)

#server.event-handler = "freebsd-kqueue" 
#server.event-handler = "libev" 

The problem is then I paste into Nemo/Nautilus address line dav://192.168.1.250:8080/webdav/ the file manager does not open the destination but is stuck into trying to open the destination. The file manager confirms that the destination is valid (e.x. dav://192.168.1.250:8080/ does not work but dav://192.168.1.250:8080/webdav/ does work) but can't open it.

If I try $HTTP["url"] =~ "^/($|/)" instead of $HTTP["url"] =~ "^/webdav($|/)" Nemo/Nautilus works, opens dav://192.168.1.250:8080/ I see the files/folders as generic files see https://ibb.co/xLhw7qb - of course I can't work with that.
I tried both to see if it would work with Nemo/Nautilus but it did not help:
server.event-handler = "freebsd-kqueue"
server.network-backend = "freebsd-sendfile"

btw i changed the port from 8080 to 80.

trying to open the files with a text editor i get HTTP error: Method Not Allowed

The behavior you are seeing is a bug in gvfs. There is a similar bug in Microsoft-WebDAV-MiniRedir, Microsoft's WebDAV client User-Agent.

diff --git a/src/mod_webdav.c b/src/mod_webdav.c
index 6c0496ba..ef97fe03 100644
--- a/src/mod_webdav.c
+++ b/src/mod_webdav.c
@@ -3941,14 +3941,20 @@ mod_webdav_propfind (request_st * const r, const plugin_config * const pconf)
             if (vb && 0 == strncmp(vb->ptr, "Microsoft-WebDAV-MiniRedir/",
                                    sizeof("Microsoft-WebDAV-MiniRedir/")-1)) {
                 /* workaround Microsoft-WebDAV-MiniRedir bug */
                 /* (MS File Explorer unable to open folder if not redirected) */
                 http_response_redirect_to_directory(r, 308);
                 return HANDLER_FINISHED;
             }
+            if (vb && 0 == strncmp(vb->ptr, "gvfs/", sizeof("gvfs/")-1)) {
+                /* workaround gvfs bug */
+                /* (gvfs unable to open folder if not redirected) */
+                http_response_redirect_to_directory(r, 308);
+                return HANDLER_FINISHED;
+            }
             /* set "Content-Location" instead of sending 308 redirect to dir */
             if (!http_response_redirect_to_directory(r, 0))
                 return HANDLER_FINISHED;
             buffer_append_string_len(&r->physical.path,    CONST_STR_LEN("/"));
             buffer_append_string_len(&r->physical.rel_path,CONST_STR_LEN("/"));
         }
     }

The patch for to workaround gvfs will be included in the upcoming lighttpd 1.4.56 release.

Thank you for the details of how you were using the clients.

Just to note gvfs-mount command seems to be deprecated but I hope gvfs is not. Samba example shown in cmd: /run/user/1000/gvfs/smb-share:server=192.168.1.250,share=pkjc$
OLD: gvfs-mount smb://192.168.0.4/tmp
NEW: gio mount smb://192.168.0.4/tmp

Thanks of taking the time. Have a nice day.
Next question would be how to fix upload speed (only 20mb/s on 1 gbps lan) in nextcloud so far the only solution I have seen is disabling http2 in the webserver but lightttpd does not have http2. :D Might be a sabredav bug no one can find it...

Maybe it would be more wise to ask gnome devs to fix the bug? It is an open source project.

Maybe it would be more wise to ask gnome devs to fix the bug? It is an open source project.

Maybe you could do that?

Next question would be how to fix upload speed (only 20mb/s on 1 gbps lan) in nextcloud so far the only solution I have seen is disabling http2 in the webserver but lightttpd does not have http2.

@montvid lighttpd does have HTTP/2 since lighttpd 1.4.56 (and enabled by default since lighttpd 1.4.59)

As for upload speed, others have suggested trying ssl.read-ahead = "enable" to configure openssl libs under lighttpd. The default is disabled since small embedded systems might be slower than the network speed, and in that case ssl.read-ahead = "enable" might tie up lighttpd processing only that one connection. However, if your system can handle the network speed, ssl.read-ahead = "enable" might be a big performance improvement for upload speeds.

If you want to see if the issue is nextcloud or somewhere else, you can have lighttpd buffer the upload to disk using server.stream-request-body = 0, which is the default in lighttpd, before lighttpd passes the request on to nextcloud.