https://bugs.documentfoundation.org/show_bug.cgi?id=154223
Bug ID: 154223
Summary: WebDAV broken with having a proxy configured and/or
HTTPS
Product: LibreOffice
Version: 7.4.4.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
