After upgrading from LibreOffice 7.3.6.2 to 7.4.4.2 (on gentoo Linux x86_64), I had issues with WebDAV: The "Open Remote..." dialog would never update with a file/directory listing even when configuring/switching between several WebDAV resources (that all work when accessed using Dolphin, cadaver, curl, ...). Furthermore, the dialog to ask for credentials (required for most of those resources) never comes up. Eventually (full story below) I figured out that manually setting the proxy to 'none' (or, at least in 7.5.2.1 on gentoo, having the WebDAV host as an exception in my proxy auto configuration script) will allow WebDAV to work correctly. All newer versions/builds that I tried had the same problem: 7.4.5.1, 7.5.1.2, 7.5.2.1 (all gentoo builds); as well as AppImages for 7.4.6.2 and 7.5.1.2 from https://www.libreoffice.org/download/appimage/ as well as dev build https://git.libreoffice.org/core/+log/c253fc3877fd91f4345feb60dacb6565f9a2509b from https://dev-builds.libreoffice.org/daily/master/current.html N.B.: The 7.5.1.2 AppImage as well as the 7.6 dev build have an additional problem in that WebDAV via HTTPS does not work leading to exactly the same symptoms; only plain HTTP works. In all affected versions, I can now reproduce the problem at will by filling in the proxy configuration manually. Digging after the issue (based on the gentoo build) led me to the following log: info:ucb.ucp.webdav:667900:667900:ucb/source/ucp/webdav-curl/webdavcontent.cxx:437: >>>>> Content::execute: start: command: open, env: present info:ucb.ucp.webdav.curl:667900:667900:ucb/source/ucp/webdav-curl/CurlSession.cxx:617: curl version: 7.87.0 x86_64-pc-linux-gnu features: 402f439d ssl: OpenSSL/1.1.1t libz: 1.2.13 info:ucb.ucp.webdav.curl:667900:667900:ucb/source/ucp/webdav-curl/CurlSession.cxx:1515: OPTIONS: http://my.intranet.host.name:8080/alfresco/webdav/Sites/HIDDEN/documentLibrary/ warn:ucb.ucp.webdav.curl:667900:667900:ucb/source/ucp/webdav-curl/CurlUri.cxx:122: curl_url_set failed: 27 warn:ucb.ucp.webdav:667900:667900:ucb/source/ucp/webdav-curl/webdavcontent.cxx:4204: OPTIONS - General DAVException (or max DAV_HTTP_REDIRECT reached) for URL <http://my.intranet.host.name:8080/alfresco/webdav/Sites/HIDDEN/documentLibrary/>, DAV ExceptionCode: 11, HTTP error: 0 info:ucb.ucp.webdav:667900:667900:ucb/source/ucp/webdav-curl/webdavcontent.cxx:3952: m_eResourceType for <http://my.intranet.host.name:8080/alfresco/webdav/Sites/HIDDEN/documentLibrary/>: 2 info:ucb.ucp.webdav.curl:667900:667900:ucb/source/ucp/webdav-curl/CurlSession.cxx:1829: HEAD: http://my.intranet.host.name:8080/alfresco/webdav/Sites/HIDDEN/documentLibrary/ warn:ucb.ucp.webdav.curl:667900:667900:ucb/source/ucp/webdav-curl/CurlUri.cxx:122: curl_url_set failed: 27 So, I had a look around https://opengrok.libreoffice.org/xref/core/ucb/source/ucp/webdav-curl/CurlUri.cxx?r=aa770d61#122 what might cause that error 27 (invalid scheme) on curl_url_set - to my surprise, I saw (only) the hostname of my proxy server being passed to curl_url_set, not the URI of the WebDAV resource as I would have expected. This gave me the idea to turn off proxy use in LibreOffice's Options -> Internet, and lo and behold, WebDAV then works correctly for me. It also works when I have the WebDAV host as an exception in my proxy auto configuration script; in one test it did NOT work when I configured the proxy manually and just put the WebDAV server host name in the "No proxy for:" field. In 7.6.0 dev, I get a different log pertaining to HTTPS: info:ucb.ucp.webdav.curl:27359:27429:ucb/source/ucp/webdav-curl/CurlSession.cxx:1341: DAVException; (first) 0 bytes of data received: info:ucb.ucp.webdav:27359:27359:ucb/source/ucp/webdav-curl/webdavcontent.cxx:437: >>>>> Content::execute: start: command: open, env: present info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:619: curl version: 7.88.1 x86_64-pc-linux-gnu features: 5128a2dd ssl: NSS/3.88.1 libz: 1.2.13 info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:1523: OPTIONS: /alfresco/webdav/Sites/ info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: !!! WARNING !!! info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: This is a debug build of libcurl, do not use in production. info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: STATE: INIT => CONNECT handle 0x4995df8; line 1933 (connection #-5000) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Added connection 0. The cache now contains 1 members info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: STATE: CONNECT => RESOLVING handle 0x4995df8; line 1979 (connection #0) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: STATE: RESOLVING => CONNECTING handle 0x4995df8; line 2053 (connection #0) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Trying 192.168.555.555:443... == [ !!! IP intentionally obfuscated, I know that 555 is not valid here !!! ] == info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Connected to my.webdav.host.name (192.168.555.555) port 443 (#0) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Initializing NSS with certpath: sql:/etc/pki/nssdb info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Unable to initialize NSS database: -5925 (PR_CALL_ONCE_ERROR) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Initializing NSS with certpath: none info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Unable to initialize NSS: -5925 (PR_CALL_ONCE_ERROR) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: multi_done: status: 77 prem: 1 done: 0 info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: multi_done, not re-using connection=0, forbid=0, close=1, premature=1, conn_multiplex=0 info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: The cache now contains 0 members info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Curl_disconnect(conn #0, dead=1) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Closing connection 0 info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:288: debug log: 0x4995df8: Expire cleared (transfer 0x4995df8) warn:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:964: curl_easy_perform failed: (77) Unable to initialize NSS: -5925 (PR_CALL_ONCE_ERROR) info:ucb.ucp.webdav.curl:27359:27359:ucb/source/ucp/webdav-curl/CurlSession.cxx:1341: DAVException; (first) 0 bytes of data received: warn:ucb.ucp.webdav:27359:27359:ucb/source/ucp/webdav-curl/webdavcontent.cxx:4204: OPTIONS - General DAVException (or max DAV_HTTP_REDIRECT reached) for URL <https://my.webdav.host.name:443/alfresco/webdav/Sites/>, DAV ExceptionCode: 7, HTTP error: 0 FWIW, /etc/pki/nssdb exists on my system and contains a valid copy (among others) of the CA backing my WebDAV host's certificate, according to certutil. I understand there's something going on with using NSS vs OpenSSL for HTTPS/TLS/certificate validation causing the gentoo builds to switch their preference between these mechanisms, albeit also towards NSS if I understand it correctly. I had specifically been trying out a gentoo build using OpenSSL while I was tracking down the issue above. Currently, I'm running 7.4.4.2 gentoo built against nss (no logs because it's a release build), and with proxy turned off HTTPS also works correctly for me.
Michael: I think it may interest you since it concerns Curl
It seems, last curl upgrade of 7.6 (7.5, 7.4.6) caused a similar problem to your experience with 7.6 with Micro Focus Vibe WebDaV server, see Bug 154224. I started to revert the upgrade in 7.4 development branch to fix this new (committed on 2023-02-23) problem there: https://gerrit.libreoffice.org/c/core/+/149141
FYI: last Curl update to 8.0 solved the similar Bug 154224 (also the older tdf#152493).
Hi Joe Can you please test if your issue is resolved in a recent master build, or in the just-released 7.5.2, or in the 7.4.7 pre-release? Thank you!
Dear Joe Breuer, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
checked with tomcat 9.0.31 OK tomcat 9.0.36 KO tomcat 9.0.58 KO tomcat 9.0.69 KO libreoffice send a lot of PROPFIND , is tomcat response not correct ?
Dear Joe Breuer, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp