[Solved] The previous workaround for GVFS is breaking the new version of GVFS
Added by ihipop almost 3 years ago
there is a workaround for GVFS to send a force redirect from "dir" to "dir/"
this prevent the new version GVFS from working
https://redmine.lighttpd.net/boards/2/topics/9516?r=9526#message-9526
when I first open the "dav://example.com/" URI
GVFS send a "dir/" location to server, which works well
when I enter sub-dir "dir"
GVFS send a "dir" location to server, after server response with a 308 redirect,the GVFS stop working
I think the best workaround is to return the same thing for both "dir" and "dir/"
GVFS version : 1.50.1
Distro: Manjaro Linux
Replies (29)
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
Please start with How to get support
You have not shared your lighttpd version or lighttpd.conf.
Which version of GVFS stopped working with which version of lighttpd?
I think the best workaround is to return the same thing for both "dir" and "dir/"
Have you read the specification for the WebDAV protocol? Please cite the specification to support your "thoughts".
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
I have not read the specification for the WebDAV protocol, and sorry for my "thoughts".
Here is my lighttpd version
lighttpd - 1.4.61-1
the GVFS version is already described above: GVFS version : 1.50.1
here is my conf
- /opt/etc/lighttpd/lighttpd.conf
server.document-root = "/userdisk/data/.data/www"
server.upload-dirs = ( "/userdisk/data/.data/tmp" )
server.errorlog = "/opt/var/log/lighttpd/error.log"
server.pid-file = "/opt/var/run/lighttpd.pid"
#server.username = "http"
#server.groupname = "www-data"
index-file.names = ( "index.php", "index.html",
"index.htm", "default.htm",
)
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
### Features
#https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_feature-flagsDetails
server.feature-flags += ("server.graceful-shutdown-timeout" => 5)
#server.feature-flags += ("server.graceful-restart-bg" => "enable")
### Options that are useful but not always necessary:
#server.chroot = "/"
server.port = 81
#server.bind = "localhost"
#server.tag = "lighttpd"
#server.errorlog-use-syslog = "enable"
#server.network-backend = "writev"
### Use IPv6 if available
#include_shell "/opt/share/lighttpd/use-ipv6.pl"
#server.use-ipv6 = "enable"
#server.set-v6only = "disabled"
dir-listing.encoding = "utf-8"
#dir-listing.activate = "enable"
include "/opt/etc/lighttpd/mime.conf"
include "/opt/etc/lighttpd/conf.d/*.conf"
- /opt/etc/lighttpd/conf.d/30-webdav.conf
####################################################################### ## ## WebDAV Module ## --------------- ## ## See https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModWebDAV ## server.modules += ( "mod_webdav" ) $SERVER["socket"] == ":5005" { include "user_conf.d/5005_dav.conf" } $SERVER["socket"] == "[::]:5005" { include "user_conf.d/5005_dav.conf" } ## #######################################################################
- /opt/etc/lighttpd/user_conf.d/5005_dav.conf
auth.require = ( "/" => ( "method" => "basic", "realm" => "Server Status", "require" => "valid-user" ), ) server.document-root = "/userdisk/data/.data/www/dav" ## ## enable webdav for this location ## webdav.activate = "enable" ## ## By default the webdav url is writable. ## Uncomment the following line if you want to make it readonly. ## #webdav.is-readonly = "enable" ## ## SQLite database for WebDAV properties and WebDAV locks ## webdav.sqlite-db-name = home_dir + "/webdav_5005.db" ## ## Log the XML Request bodies for debugging ## #webdav.log-xml = "disable" ## ## mod_webdav further tunables ## See online doc: ## https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModWebDAV ## #webdav.opts = ( ... )
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
lighttpd 1.4.61 contains a patch for https://redmine.lighttpd.net/boards/2/topics/10081 which also addresses https://gitlab.gnome.org/GNOME/gvfs/-/issues/545 (which to my knowledge was not reported here.) Since you're already running lighttpd 1.4.61, that should not be your issue. (FYI: Latest lighttpd release is lighttpd 1.4.64.)
Which version of GVFS stopped working with which version of lighttpd?
If this previously worked for you, which versions worked?
GVFS send a "dir" location to server, after server response with a 308 redirect,the GVFS stop working
Please see the troubleshooting steps taken in https://gitlab.gnome.org/GNOME/gvfs/-/issues/545
Seeing the details of what GVFS is sending and receiving from lighttpd may be more useful than "GVFS stop working"
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
If this previously worked for you, which versions worked?
I don't knwo exactly, Manjaor is a rolling upgrade distro , it used to work in old version of GVFS , I'm not use webdav every day, after some updates, it stop working
Please see the troubleshooting steps taken in https://gitlab.gnome.org/GNOME/gvfs/-/issues/545
Seeing the details of what GVFS is sending and receiving from lighttpd may be more useful than "GVFS stop working"
I'v already do that, when i enter the sub dir ,it failed, and,only one message was fired:
dav: send_reply(0x5582bc6d3350), failed=0 () dav: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=1361793) dav: Queued new job 0x7f2e90002540 (GVfsJobQueryInfo) dav: Query info /qBittorrent-Download dav: send_reply(0x7f2e90002540), failed=1 (Message is already in session queue)
and I start wireshark to sniff the traffic, when it failed ,lighttpd returned a 308,which maybe from this patch https://redmine.lighttpd.net/boards/2/topics/9516?r=9526#message-9526 ,I'v posted the screenshot of wireshark
and I also use wireshark to sniff the traffic of GVFS to my Synology NAS, they're working fine, and the Synology NAS do the "thoughts" that I've sorry for :)
does these info helps more than a "Message is already in session queue" ?
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
does these info helps more than a "Message is already in session queue" ?
Not much.
Please see the troubleshooting steps taken in https://gitlab.gnome.org/GNOME/gvfs/-/issues/545 to get more info from GVFS.
Please see the troubleshooting steps taken in https://redmine.lighttpd.net/boards/2/topics/10081
lighttpd debug variables and webdav.log-xml = "enable"
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
here are the log files
just as what i saw in wireshark,after lighttpd returned a "308" from "dir" to "dir/" ,GVFS stop at an error
while Synology NAS do the "thoughts", return the same content of "dir/" as "dir" with response "207", and GVFS is happy with it.
tail /opt/var/log/lighttpd/error.log -f 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:resourcetype/>\n<D:getcontentlength/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/</D:href>\n<D:propstat>\n<D:prop>\n<D:resourcetype><D:collection/></D:resourcetype><D:getcontentlength>4096</D:getcontentlength></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/</D:href>\n<D:propstat>\n<D:prop>\n<D:resourcetype><D:collection/></D:resourcetype><D:getcontentlength>4096</D:getcontentlength></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/%E4%B8%8B%E8%BD%BD/</D:href>\n<D:propstat>\n<D:prop>\n<D:resourcetype><D:collection/></D:resourcetype><D:getcontentlength>4096</D:getcontentlength></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3027358892"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sat, 29 Jan 2022 10:26:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3027358892"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sat, 29 Jan 2022 10:26:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"183805078"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Mon, 23 May 2022 13:51:12 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/%E4%B8%8B%E8%BD%BD/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3634907560"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Fri, 11 Feb 2022 05:33:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3027358892"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sat, 29 Jan 2022 10:26:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3027358892"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sat, 29 Jan 2022 10:26:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/qBittorrent-Download/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"183805078"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Mon, 23 May 2022 13:51:12 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/.temp/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3581254717"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Mon, 23 May 2022 19:41:40 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/.torrents/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3552076656"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Fri, 11 Feb 2022 02:46:34 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/.3c335730d4ecd1e8e8ed3c8aa5abe065163c7747.parts</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>1870036</D:getcontentlength><D:getcontenttype>application/octet-stream</D:getcontenttype><D:getetag>"2401288550"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Fri, 11 Feb 2022 09:02:22 GMT</D:getlastmodified><D:resourcetype/></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/ThunderDB/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"2839149011"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sun, 22 May 2022 07:20:24 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/Movie/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"2671427565"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Fri, 20 May 2022 00:35:28 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/TDDOWNLOAD</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>211</D:getcontentlength><D:getcontenttype>application/octet-stream</D:getcontenttype><D:getetag>"1442749758"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sat, 26 Feb 2022 14:56:18 GMT</D:getlastmodified><D:resourcetype/></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/qBittorrent-Download/TV/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"1729862679"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Mon, 23 May 2022 19:41:40 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n 2022-05-27 01:08:56: (../src/mod_webdav.c.3640) XML-request-body: <?xml version="1.0" encoding="utf-8" ?>\n <D:propfind xmlns:D="DAV:">\n <D:prop>\n<D:creationdate/>\n<D:displayname/>\n<D:getcontentlength/>\n<D:getcontenttype/>\n<D:getetag/>\n<D:getlastmodified/>\n<D:resourcetype/>\n </D:prop>\n </D:propfind> 2022-05-27 01:08:56: (../src/mod_webdav.c.744) XML-response-body: <?xml version="1.0" encoding="utf-8"?>\n<D:multistatus xmlns:D="DAV:" xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">\n<D:response>\n<D:href>/%E4%B8%8B%E8%BD%BD/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"3634907560"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Fri, 11 Feb 2022 05:33:02 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/%E4%B8%8B%E8%BD%BD/ThunderDB/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"345636304"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Sun, 22 May 2022 07:20:24 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n<D:response>\n<D:href>/%E4%B8%8B%E8%BD%BD/TDDOWNLOAD/</D:href>\n<D:propstat>\n<D:prop>\n<D:getcontentlength>4096</D:getcontentlength><D:getcontenttype>httpd/unix-directory</D:getcontenttype><D:getetag>"1815790183"</D:getetag><D:getlastmodified ns0:dt="dateTime.rfc1123">Tue, 16 Oct 2018 11:45:34 GMT</D:getlastmodified><D:resourcetype><D:collection/></D:resourcetype></D:prop>\n<D:status>HTTP/1.1 200 OK</D:status>\n</D:propstat>\n<D:propstat>\n<D:prop>\n<creationdate xmlns="DAV:"/><displayname xmlns="DAV:"/></D:prop>\n<D:status>HTTP/1.1 404 Not Found</D:status>\n</D:propstat>\n</D:response>\n</D:multistatus>\n
The GVFS log is too long to pasted
I attached it
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
And I digged up the source tree of lighttpd-1.4.64,
https://github.com/lighttpd/lighttpd1.4/blob/73bd6b41d3f8608663e93962cbb60832a457a415/src/mod_webdav.c#L4219-L4224
https://github.com/lighttpd/lighttpd1.4/blob/lighttpd-1.4.64/src/mod_webdav.c#L4219-L4224
the previous patch is still there https://redmine.lighttpd.net/boards/2/topics/9516?r=9526#message-9526
I installed it and test with previous configurations, the problem can be recurrent.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
In the gvfsd.log, I see that the client is sending Apply-To-Redirect-Ref: T
lighttpd does not currently support MKREDIRECTREF.
In response to OPTIONS, lighttpd does not include MKREDIRECTREF in Allow, and lighttpd does not include redirectrefs in DAV.
Therefore, the GVFS client should not assume support for redirectrefs, and should not misbehave when sent a redirect, even when the client sends a request containing Apply-To-Redirect-Ref: T
https://datatracker.ietf.org/doc/html/rfc4437#section-12.2
If the Apply-To-Redirect-Ref header is used on a request to any other
sort of resource besides a redirect reference resource, the server
MUST ignore it.
lighttpd is ignoring Apply-To-Redirect-Ref: T.
Since GVFS apparently thinks there is an error when lighttpd sends 308 Permanent Redirect, it is possible that GVFS is somehow mishandling lighttpd's response. That is my current theory.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
Also, I posted a link: lighttpd debug variables and webdav.log-xml = "enable"webdav.log-xml is of limited utility without request and response headers. Please read the link.
I was able to respond above only because the gvfsd.log contains request and response headers.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
I took a quick peek in the gvfs source code and this jumped out at me from daemon/gvfsbackenddav.c
else if (message_should_apply_redir_ref (msg))
{
if (status == SOUP_STATUS_MOVED_PERMANENTLY ||
status == SOUP_STATUS_TEMPORARY_REDIRECT)
{
const char *method = soup_message_get_method (msg);
/* Only cross-site redirect safe methods */
if (method == SOUP_METHOD_GET &&
method == SOUP_METHOD_HEAD &&
method == SOUP_METHOD_OPTIONS &&
method == SOUP_METHOD_PROPFIND)
redirect = TRUE;
}
/* Two possibilities:
*
* 1) It's a non-redirecty 3xx response (300, 304,
* 305, 306)
* 2) It's some newly-defined 3xx response (308+)
*
* We ignore both of these cases. In the first,
* redirecting would be explicitly wrong, and in the
* last case, we have no clue if the 3xx response is
* supposed to be redirecty or non-redirecty. Plus,
* 2616 says unrecognized status codes should be
* treated as the equivalent to the x00 code, and we
* don't redirect on 300, so therefore we shouldn't
* redirect on 308+ either.
*/
}
https://www.rfc-editor.org/rfc/rfc7538
RFC 7538 defines 308 Permanent Redirect status code and was published in April 2015.
libsoup supports SOUP_STATUS_TEMPORARY_REDIRECT = 307, SOUP_STATUS_PERMANENT_REDIRECT = 308,
I think gvfs is over 7 years overdue to recognize 308 Permanent Redirect. (Whether or not this is your issue remains to be seen. However, it is definitely a shortcoming in gvfs.)
It is possible (unverified) that gvfs commit beaaf78b "dav, http: port to libsoup3", included in gvfs 1.49.90 released 11 Feb 2022 introduced the issue you are seeing.
Please test downgrading your gvfs libraries to see if you can confirm.
(BTW, lighttpd 1.4.64 was released 19 Jan 2022, so if you're running lighttpd 1.4.61, and yet running newer gvfs libs, Manjaro is slow in staying up-to-date and/or you are not periodically updating your system in a timely fashion. It's almost Jun 2022 as I write this.)
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
I submitted a patch to gvfs: https://gitlab.gnome.org/GNOME/gvfs/-/issues/628
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
thanks for your kindly reply
And
BTW, lighttpd 1.4.64 was released 19 Jan 2022, so if you're running lighttpd 1.4.61, and yet running newer gvfs libs, Manjaro is slow in staying up-to-date and/or you are not periodically updating your system in a timely fashion. It's almost Jun 2022 as I write this.
Sorry for the missing details
Lighttpd 1.4.61 was running in a tiny arm seeding box ,and was installed by Entware
In the package repo of Manjaro ,the Lighttpd is up-to-date
I have the problem when I visiting the WebDAV running by Lighttpd in the seeding box
And, I will test the patch later and give some feedback here later
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
I make a quick test with lighttpd
diff --git a/src/mod_webdav.c b/src/mod_webdav.c
index 3a3c9c56..9b58f10f 100644
--- a/src/mod_webdav.c
+++ b/src/mod_webdav.c
@@ -4219,7 +4219,7 @@ mod_webdav_propfind (request_st * const r, const plugin_config * const pconf)
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);
+ http_response_redirect_to_directory(r, 307);
return HANDLER_FINISHED;
}
/* set "Content-Location" instead of sending 308 redirect to dir */
I change the lighttpd response code from "308" to "307" to suite your patch
it's still not working
I enabled
debug.log-request-header = "enable" debug.log-response-header = "enable"
here attached the logs
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
There does not appear to be anything wrong with lighttpd's response.
2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: PROPFIND /anydesk HTTP/1.1 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Accept-Encoding: gzip, deflate 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: User-Agent: gvfs/1.50.1 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Accept-Language: en 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Connection: Keep-Alive 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Host: 127.0.0.1:5005 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Content-Type: application/xml 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Content-Length: 235 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Authorization: Basic MTIzOjQ1Ng== 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Depth: 0 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: Apply-To-Redirect-Ref: T 2022-05-27 10:36:26: (connections.c.770) fd:15 rqst: 2022-05-27 10:36:26: (response.c.164) fd:15 resp: HTTP/1.1 307 Temporary Redirect 2022-05-27 10:36:26: (response.c.164) fd:15 resp: Location: /anydesk/ 2022-05-27 10:36:26: (response.c.164) fd:15 resp: Content-Length: 0 2022-05-27 10:36:26: (response.c.164) fd:15 resp: Date: Fri, 27 May 2022 02:36:26 GMT 2022-05-27 10:36:26: (response.c.164) fd:15 resp: Server: lighttpd/1.4.64 2022-05-27 10:36:26: (response.c.164) fd:15 resp:
You might try commenting out the workaround for gvfs in lighttpd mod_webdav.c to see if that workaround is still necessary. Comment out this whole block, which is present in two places in lighttpd mod_webdav.c:
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);
+ http_response_redirect_to_directory(r, 307);
return HANDLER_FINISHED;
}
As an aside, is GVFS really that wasteful in sending gratuitous Connection: Keep-Alive with an HTTP/1.1 request? That is redundant with an HTTP/1.1 request. Feel free to post a patch to gvfs telling them to remove the redundant and wasteful header with HTTP/1.1. Sending that may have been more reasonable 20 years ago when an HTTP/1.0 server (or an HTTP/1.0 proxy) might have received the request, but is archaic today. [Edit: After a quick search, I did not see what sends Connection: Keep-Alive in the gvfs codebase, so that header is probably being added by something else archaic.]
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
Did you try downgrading gvfs to 1.49.1 -- or other version earlier than 1.49.90 -- to see if the issue goes away?
FYI: I likely won't be able to respond further until some time next week.
If you can narrow down the issue to upgrading from lighttpd 1.4.xx to lighttpd 1.4.xx+1, then I can certainly work on a fix.
If you can narrow down the issue to upgrading from gvfs 1.xx.xx to 1.xx.xx+?, then that will at least help focus the issue.
What client are you using? (As someone who does not use gvfs, but does use lighttpd mod_webdav, where would you tell me to begin to repro what you are seeing?)
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
You might try commenting out the workaround for gvfs in lighttpd mod_webdav.c to see if that workaround is still necessary.
I already tried yesterday
commenting out the workaround make the problem that this workaround want to fix appear again
and also,I tested the other WebDav servers they are working well with this version GVFS, because the reply "dir" as "dir/" if "dir" is really a dir,
instead of a redirected, and GVFS is happy with it.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
What client are you using? (As someone who does not use gvfs, but does use lighttpd mod_webdav, where would you tell me to begin to repro what you are seeing?)
Just install latest Manjaro Distro and run
sudo pacman -Syu
to make your system is latest
then you will get
GVFS version : 1.50.1
Nautilus: 42.1.1
use gio/shell command or nautilus to access dav://example.com makes no difference because the share the same gvfsd
I will try to downgrade GVFS this weekend to try to narrow down the version that happened this problem (if ,the downgrade don't crash my system :0) )
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
commenting out the workaround make the problem that this workaround want to fix appear again
and also,I tested the other WebDav servers they are working well with this version GVFS, because the reply "dir" as "dir/" if "dir" is really a dir,
instead of a redirected, and GVFS is happy with it.
Do you realize that lighttpd will respond to "/dir" and set Content-Location: /dir/ if you comment out the special-case for gvfs? [Edit: this is true beginning in lighttpd 1.4.65] That lighttpd needs that special-case for gvfs is due to gvfs not handling lighttpd's original and default response to "/dir" (which should be to WebDAV collection "/dir/")
Instead of 307 in your test patch above, see if 302 makes a difference.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
Instead of 307 in your test patch above, see if 302 makes a difference.
302 makes no difference.
Do you realize that lighttpd will respond to "/dir" and set Content-Location: /dir/ if you comment out the special-case for gvfs? That lighttpd needs that special-case for gvfs is due to gvfs not handling lighttpd's original and default response to "/dir" (which should be to WebDAV collection "/dir/")
the other WebDav servers I'v tried does not response "/dir" with "Content-Location: /dir/" ,they make the same response as the "/dir/" with a response of "207 Multi-Status" ,this is what I'm talking about at the first time. The content had a "<D:href>/music/</D:href>" to GVFS
Here is the request of GVFS to "/music" and response from my Synogoly NAS WebDav Server
> PROPFIND /music HTTP/1.1 > Soup-Debug-Timestamp: 1653623605 > Soup-Debug: SoupSession 1 (0x55e0b585d980), SoupMessage 14 (0x55e0b58765c0), GSocket 5 (0x55e0b5846fa0) > Accept-Encoding: gzip, deflate > User-Agent: gvfs/1.50.1 > Accept-Language: en > Connection: Keep-Alive > Host: 192.168.69.9:5005 > Content-Type: application/xml > Content-Length: 235 > Authorization: Basic [media:**********] > Depth: 0 > Apply-To-Redirect-Ref: T > > <?xml version="1.0" encoding="utf-8" ?> > <D:propfind xmlns:D="DAV:"> > <D:prop> > <D:creationdate/> > <D:displayname/> > <D:getcontentlength/> > <D:getcontenttype/> > <D:getetag/> > <D:getlastmodified/> > <D:resourcetype/> > </D:prop> > </D:propfind> < HTTP/1.1 207 Multi-Status < Soup-Debug-Timestamp: 1653623605 < Soup-Debug: SoupMessage 13 (0x55e0b58763a0) < Date: Fri, 27 May 2022 03:53:25 GMT < Server: Apache < Content-Length: 734 < Keep-Alive: timeout=5, max=96 < Connection: Keep-Alive < Content-Type: text/xml; charset="utf-8" < < <?xml version="1.0" encoding="utf-8"?> < <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2019-07-05T02:40:37Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddfe703dc5a0"</lp1:getetag> < <lp1:getlastmodified>Mon, 02 May 2022 02:49:18 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < </D:multistatus> dav: send_reply(0x7f0d9c004d20), failed=0 () < HTTP/1.1 207 Multi-Status < Soup-Debug-Timestamp: 1653623605 < Soup-Debug: SoupMessage 12 (0x55e0b5876180) < Date: Fri, 27 May 2022 03:53:25 GMT < Server: Apache < Content-Length: 4045 < Keep-Alive: timeout=5, max=99 < Connection: Keep-Alive < Content-Type: text/xml; charset="utf-8" < < <?xml version="1.0" encoding="utf-8"?> < <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2019-07-05T02:40:37Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddfe703dc5a0"</lp1:getetag> < <lp1:getlastmodified>Mon, 02 May 2022 02:49:18 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/%e5%9f%9f%e5%a4%96%e6%ad%8c%e6%9b%b2/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2022-02-11T07:33:39Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"5000-5ddf3a198b94c"</lp1:getetag> < <lp1:getlastmodified>Sun, 01 May 2022 13:55:41 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/%e4%ba%ba%e5%b7%a5%e6%95%b4%e7%90%86%e7%ba%af%e9%9f%b3%e4%b9%90/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2022-02-11T07:36:17Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddf3f5b65aae"</lp1:getetag> < <lp1:getlastmodified>Sun, 01 May 2022 14:19:12 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/.Trash-1000/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2022-05-01T03:31:18Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddeae89d0be2"</lp1:getetag> < <lp1:getlastmodified>Sun, 01 May 2022 03:31:18 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/%e5%8d%8e%e8%af%ad%e6%ad%8c%e6%9b%b2/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2022-02-11T07:38:19Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"3000-5ddef312478f6"</lp1:getetag> < <lp1:getlastmodified>Sun, 01 May 2022 08:37:54 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/pure-music/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2022-02-11T07:44:19Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddf3fbf2ca2e"</lp1:getetag> < <lp1:getlastmodified>Sun, 01 May 2022 14:20:57 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < </D:multistatus> dav: send_reply(0x55e0b5858a50), failed=0 () < HTTP/1.1 207 Multi-Status < Soup-Debug-Timestamp: 1653623605 < Soup-Debug: SoupMessage 14 (0x55e0b58765c0) < Date: Fri, 27 May 2022 03:53:25 GMT < Server: Apache < Content-Length: 734 < Keep-Alive: timeout=5, max=100 < Connection: Keep-Alive < Content-Type: text/xml; charset="utf-8" < < <?xml version="1.0" encoding="utf-8"?> < <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> < <D:response xmlns:lp1="DAV:" xmlns:lp2="http://apache.org/dav/props/" xmlns:g0="DAV:"> < <D:href>/music/</D:href> < <D:propstat> < <D:prop> < <lp1:creationdate>2019-07-05T02:40:37Z</lp1:creationdate> < <D:getcontenttype>httpd/unix-directory</D:getcontenttype> < <lp1:getetag>"1000-5ddfe703dc5a0"</lp1:getetag> < <lp1:getlastmodified>Mon, 02 May 2022 02:49:18 GMT</lp1:getlastmodified> < <lp1:resourcetype><D:collection/></lp1:resourcetype> < </D:prop> < <D:status>HTTP/1.1 200 OK</D:status> < </D:propstat> < <D:propstat> < <D:prop> < <g0:displayname/> < <g0:getcontentlength/> < </D:prop> < <D:status>HTTP/1.1 404 Not Found</D:status> < </D:propstat> < </D:response> < </D:multistatus>
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
You wrote:
use gio/shell command or nautilus to access dav://example.com makes no difference because the share the same gvfsd
On Fedora 36 Xfce (my test system), gio mount dav://localhost:8080/ works for me to a lighttpd 1.4.65 (local dev) instance running mod_webdav, and then I can do things like MOVE and DELETE successfully on the mounted filesystem from within the thunar file manager.
I wrote:
(As someone who does not use gvfs, but does use lighttpd mod_webdav, where would you tell me to begin to repro what you are seeing?)
Please provide some guidance on how to reproduce this issue (besides "install Manjaro").
/usr/bin/gio on my system comes from the glib2 package and does not appear to depend directly on gvfs (which is 1.50.1 on my system),
There must be some missing steps on asking systemd to run gvfsd or something like that. Again, I am not someone who uses gvfsd.
Some guidance would be appreciated.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
Instead of 307 in your test patch above, see if 302 makes a difference.
302 makes no difference.
It might be useful if you open an issue on gvfs gitlab and ask if gvfs DAV PROPFIND can handle 3xx responses. From a very quick look in the gvfs code, it appears to me that gvfs DAV is expecting 207 Multi-Status and might not handle 3xx (unless libsoup handles that under the covers. ... I have not looked there, but I don't think libsoup should handle that for the app).
However, if things used to work for you, it would be very useful to find out approx which versions of lighttpd and/or gvfs changed to make things not work for you.
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
/usr/bin/gio on my system comes from the glib2 package and does not appear to depend directly on gvfs (which is 1.50.1 on my system),
run
gio mount dav://127.0.0.1:5005
will launch gvfsd in background
I am not someone who uses gvfsd.
Some guidance would be appreciated.
just like using gio command, location to a dav:// URI in nautilus address bar will also communicate to GVFSD, the mount and credentials are managed by GVFSD
use gio/shell command or nautilus to access dav://example.com makes no difference because the share the same gvfsd
On Fedora 36 Xfce (my test system), gio mount dav://localhost:8080/ works for me to a lighttpd 1.4.65 (local dev) instance running mod_webdav, and then I can do things like MOVE and DELETE successfully on the mounted filesystem from within the thunar file manager.
are you only accessing the root directory ? I can WRITE or DELETE files on the mounted filesystem only in the root directory, both shell command ls and nautilus can not enter the subdir, the gio list dav://example.com/subdir command works because it will fire a PROPFIND cmd to "subdir/" ,not "subdir"
here is all the files and steps you need
- lighttpd.conf.tar.gz is the conf files I'm using , extract it to /tmp, then start lighttpd with command
lighttpd -Df /tmp/lighttpd/lighttpd.conf
- close all running GVFSD/nautilus because we want to view the detail log of GVFSD
pkill gvfs; pkill nautilus - manually launch a DEBUG level GVFSD so we can view the detail log
GVFS_HTTP_DEBUG=all GVFS_DEBUG=1 $(find /usr/lib* -name gvfsd 2>/dev/null) --replace 2>&1 | tee gvfsd.log
- you can mount the dav://127.0.0.1:5005 by nautilus or gio,they are both the same
here by gio command as examplegio mount dav://127.0.0.1:5005 gio info dav://127.0.0.1:5005 localPath=$(gio info dav://127.0.0.1:5005 |grep 'local path:'|grep -oP "/.*") cd $localPath ls # try other sub dir operation,you will get errors
However, if things used to work for you, it would be very useful to find out approx which versions of lighttpd and/or gvfs changed to make things not work for you.
I never change the version of lighttpd in my ARM seeding box,it's always has been version 1.4.61, and when I launch a lighttpd v1.4.64 on my machine ,the problem still there, the only thing make the difference that is after a serious of system update which changed the gvfsd version
I cant downgrade the GVFSD version for now,Maybe I could to is this weekend ,I will report it later
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
I tried,
downgrade GVFSD from 1.50.1 to https://archive.archlinux.org/packages/g/gvfs/gvfs-1.48.1-3-x86_64.pkg.tar.zst fix the problem immediately
gvfs-1.48.1-3 is wokring
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by ihipop almost 3 years ago
Things we know from now：
- gvfs-1.48.1-3 is wokring
- gvfs-1.50 does not accept any redirect （307/308）or "Content-Location" when PROPFIND a subdir
- other webdav server response the PROPFIND cmd of "subdir" with a "207 Multi-Status" ,just like "subdir/" ,and ,gvfs-1.50 is happy with it
RE: The previous workaround for GVFS is breaking the new version of GVFS - Added by gstrauss almost 3 years ago
There might be an unhandled interaction between gvfs and libsoup3. Please open an issue on https://gitlab.gnome.org/GNOME/gvfs (and link back here), as it may take some time to engage the developers there and the evidence currently suggests a regression somewhere between gvfs-1.48.1 and gvfs-1.50.1.
I see a number of webdav issues filed in https://gitlab.gnome.org/GNOME/gvfs
The stagnant https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/17 seems like it might be relevant.
BTW, my proposed patch in https://gitlab.gnome.org/GNOME/gvfs/-/issues/628 does not fix the issue here since when you changed lighttpd to return 307 instead of 308 for this case, that did not seem to work around the issue.
Tangentially related to this issue is another shortcoming in gvfs: gvfs does not handle (never checks) for Content-Location in gvfs daemon/gvfsbackenddav.c, which is what necessitated the initial workaround for gvfs in lighttpd mod_webdav.c.