Just for your information, from LO 7.3 LO uses Curl for WebDav instead of Neon or Serf lib. (see https://blog.allotropia.de/2022/02/07/improving-libreoffices-network-file-access/).

So even if there's indeed some bugs in 7.2.5, I'd be astonished it could be fixed in 7.2.6 or even 7.2.7 (see https://wiki.documentfoundation.org/ReleasePlan/7.2) but I may be wrong.

Would it be possible you give a try with LO 7.3.0 ?

I just tested this issue with 7.3.1 and am sorry to report that the issue also exists in that version.

(In reply to Julien Nabet from comment #1)
> Would it be possible you give a try with LO 7.3.0 ?

For me it's also confirmed broken in exactly the same way in 7.3.1.1

I've dug a little bit deeper - with SAL_LOG="+INFO.ucb", LO 7.1 logs a ton of information pertaining to the HTTP requests underlying WebDAV, ie things like:

info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/webdavcontent.cxx:449: Content::execute: start: command: open, env: present
info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/NeonSession.cxx:651: NeonSession ctor - URL <https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>
HTTP session to https://hidden.host.name:443 begins.
ssl: SNI enabled by default.
info:ucb.ucp.webdav:515394:515394:ucb/source/ucp/webdav-neon/NeonSession.cxx:868: OPTIONS - relative URL </alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>
Running pre_send hooks
Sending request headers:
OPTIONS /alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/ HTTP/1.1
Keep-Alive: 
Connection: TE, Keep-Alive
TE: trailers
Host: hidden.host.name
Pragma: no-cache
User-Agent: LibreOffice

Sending request-line and headers:
Doing DNS lookup on hidden.host.name...
req: Connecting to 192.168.23.254:443
Doing SSL negotiation.


With LO 7.2, NONE of this is logged - the only things logged at all within ucb are within/below ucb.ucp.gio:

info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_provider.cxx:36: QueryContent: https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/
info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:81: New Content ('https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/')
info:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:939: Content::execute open
warn:ucb.ucp.gio:516758:516758:ucb/source/ucp/gio/gio_content.cxx:399: ignoring GError "HTTP Client Error: Unauthorized" for <https://hidden.host.name:443/alfresco/webdav/Sites/HIDDEN/documentLibrary/!HIDDEN/>


Digging around the ucb providers in OpenGrok, it seems to me that the gio provider is erroneously chosen instead of the WebDAV one.

My source-reading fu is currently not strong enough to find the place where the decision for a particular ucb provider is actually made, and what that decision is based on.

Thank you Joe for your detailed feedback.

Michael: thought you might be interested in this one since it concerns WebDav.

so the problem is apparently that in 7.2 an URL with https:// is handled not by webdav UCP but by gio UCP - that is indeed quite surprising.

if you have basic git skills and can download a ~10gb repo, possibly this potential regression could be tracked down via bibisect, in the linux 7.2 repo:

https://wiki.documentfoundation.org/QA/Bibisect/Linux

https://bibisect.libreoffice.org/linux-64-7.2

At my current everyday location, I don't have the bandwidth, and also am space-constrained to do a bisection on a 10GB repo.

I'll try to remember when I'm at a place with better connectivity/infrastructure next.

If anyone else is in a better position to do this, your help would be greatly appreciated.

A small bit of additional information: (Today,) I have remote access to a Windows system that would be suitable for the bisection.

Alas, this problem seems Linux-specific - installing 7.2.5.2 or 7.2.6.2 on Windows, they both work fine with the same WebDAV share.

I'll see about figuring out a system/VM I can test this on under Linux.

@J. Roeleveld: What distribution could you reproduce the problem in?


The plot thickens. Using the libreoffice-still 7.2.6-1 package in Arch Linux, WebDAV works as expected (same as under Windows).

So I tried with the 7.2.5 "Basic" AppImage that I could find on my gentoo system, where I first experienced the issue. Again, WebDAV works correctly in that version.

Next, I moved the libreoffice configuration directory (in ~/.config/libreoffice) out of the way and tested again with the gentoo native package/build - and I still get the "Nonexistent file." error.

At this point, it looks like there's something up with the gentoo build/package, rather than LO itself.

I'd be super interested to hear back from J. Roeleveld, if he's also using gentoo, or, if another distribution, what's similar between the ones where the bug occurs.

As also mentioned in the bug-tracker for Gentoo, I am using Gentoo and do my best to keep my systems fully updated.

To also answer here (for completeness), I have not changed the USE-flags for libreoffice.

I got a testing environment put together, a stripped-down and minimal version of gentoo as I use it / as it comes out of the box, as it were. The there-current app-office/libreoffice-7.2.5.2-r1 package exhibits the bug, ie "Nonexistent file." instead of WebDAV browsing / file access.

I then had a look at the bibisection.

Similar to what I found in comment 8 and comment 9, the bug does not occur with either the newest 7.2 bisection build:

commit 1b8c93949b24204fe8a7b7105215c712aa132547
Date:   Tue Mar 15 11:48:19 2022 +0100
    source 6fb5a87e31b7df01f4b212ab979ae57e8d4ab4fb

nor with the oldest:

commit 1810f056660f59f79e76b8bdd6f5b902c27ce14f (HEAD, tag: oldest)
Date:   Thu Nov 26 15:52:40 2020 +0100
    source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a

Which means there's something (significant in this respect) different about the gentoo builds of LibreOffice from the ones in the bibisection repository.

I've since also tested the binary build that's available for/on gentoo (as app-office/libreoffice-bin-7.2.5.2): WebDAV also does not work, but it is subtly different: the "Open Remote..." file dialog stays empty after configuring a WebDAV service, there is no error dialog.

As J. Roeleveld also suggested - great idea! - I'll start having a look what those differences might be; using the documented release build options & environment as a starting point:

https://wiki.documentfoundation.org/Development/ReleaseBuilds#Linux_.28same_options_for_x86_.26_x86_64.29

For reference/contrast, here's the configuration that the source build in gentoo uses:

./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --docdir=/usr/share/doc/libreoffice-7.2.5.2-r1 --htmldir=/usr/share/doc/libreoffice-7.2.5.2-r1/html --libdir=/usr/lib64 --with-system-dicts --with-system-epoxy --with-system-headers --with-system-jars --with-system-libs --enable-build-opensymbol --enable-cairo-canvas --enable-largefile --enable-mergelibs --enable-python=system --enable-randr --enable-release-build --disable-breakpad --disable-bundle-mariadb --disable-ccache --disable-epm --disable-fetch-external --disable-gtk3-kde5 --disable-online-update --disable-openssl --disable-pdfium --with-extra-buildid=Gentoo official package --enable-extension-integration --with-external-dict-dir=/usr/share/myspell --with-external-hyph-dir=/usr/share/myspell --with-external-thes-dir=/usr/share/myspell --with-external-tar=/var/tmp/portage/app-office/libreoffice-7.2.5.2-r1/distdir --with-lang= --with-parallelism=6 --with-system-ucpp --with-tls=nss --with-vendor=Gentoo Foundation --with-webdav --with-x --without-fonts --without-myspell-dicts --with-help=html --without-helppack-integration --with-system-gpgmepp --without-system-jfreereport --without-system-libcmis --without-system-sane --disable-report-builder --enable-sdremote-bluetooth --disable-coinmp --enable-cups --enable-dbus --disable-debug --disable-evolution2 --disable-firebird-sdbc --disable-gstreamer-1-0 --enable-gtk3 --enable-kf5 --enable-qt5 --disable-ldap --disable-odk --disable-pdfimport --disable-postgresql-sdbc --disable-skia --without-lxml --without-system-coinmp --without-gdrive-client-id --without-gdrive-client-secret --without-java --without-doxygen --enable-dconf --enable-gio --disable-ext-nlpsolver --disable-scripting-beanshell --disable-scripting-javascript --disable-ext-wiki-publisher

The --disable-openssl does stick out a bit, although --with-tls=nss is selected explicitly. I've just checked, the working 7.1.8.1 build does the same. Hmm, and what does --enable-gio do, exactly.

Ooh, and here is a strong hint in the ./configure output:

checking for webdav library... none, disabled

... although net-libs/neon-0.32.2 is available on the system, but the gentoo build process typically takes care to isolate packages (that are not explicitly used as dependencies), and it isn't listed there.

I have an idea how to set that right in the gentoo build:
  webdav? ( net-libs/neon )
  $(use_with webdav neon)
and I will be trying this out next.

I'm guessing the "neon" bit is likely:

# grep "checking for webdav library" /var/log/portage/app-office\:libreoffice-*
/var/log/portage/app-office:libreoffice-7.1.5.2:20211012-094228.log:checking for webdav library... neon
/var/log/portage/app-office:libreoffice-7.1.7.2:20211214-144308.log:checking for webdav library... neon
/var/log/portage/app-office:libreoffice-7.1.8.1:20220302-094027.log:checking for webdav library... neon
/var/log/portage/app-office:libreoffice-7.2.5.2:20220215-091116.log:checking for webdav library... none, disabled
/var/log/portage/app-office:libreoffice-7.2.5.2-r1:20220218-080404.log:checking for webdav library... none, disabled
/var/log/portage/app-office:libreoffice-7.3.1.1-r1:20220302-085740.log:checking for webdav library... none, disabled


As you can see, 7.1.x all found "neon", 7.2.x and 7.3.x did not on my system.

Also:

# grep neon *
grep: files: Is a directory
libreoffice-7.1.8.1.ebuild:     >=net-libs/neon-0.31.1:=
libreoffice-7.1.8.1.ebuild:             --enable-neon


# grep neon *
grep: files: Is a directory
libreoffice-7.2.5.2-r1.ebuild:  >=net-libs/neon-0.31.1:=
libreoffice-7.2.6.2.ebuild:     >=net-libs/neon-0.31.1:=
libreoffice-7.3.1.3-r1.ebuild:  >=net-libs/neon-0.31.1:=
libreoffice-7.3.2.2.ebuild:     >=net-libs/neon-0.31.1:=
libreoffice-7.3.9999.ebuild:    >=net-libs/neon-0.31.1:=
libreoffice-9999.ebuild:        >=net-libs/neon-0.31.1:=


Are we missing " --enable-neon " from the " myeconfargs= " list in the ebuild?

(Not sure how to edit comments here)

"--enable-neon" was removed in the same commit as where "--with-webdav" was added. (checking the git-commits for libreoffice-9999)

This commit was done on 2022-10-31

Compile is still running, but the configure output is now showing:

checking for webdav library... neon

I added the following configure-flag to the ebuild:

--with-webdav="neon"


It is necessary to actually list the library like this.

Created attachment 179448 [details]
This ebuild works with webdav on my system

I added  " +webdav " to IUSE

I added "webdav? ( net-libs/neon )" to COMMON_DEPEND

I added " --with-webdav="neon" " to myeconfargs

The last one should still be linked to a USE-flag.

But this is a step in the right direction.

I can also confirm that configuring with:

  --with-webdav=neon

instead of

  --with-webdav

yields a WebDAV-enabled and -working LO (under gentoo).

I'll submit a suitable build patch over there.

I'm also experiencing this same issue on the debian buster libreoffice package. I've tried the debian buster-backports build. Both experience this problem.