[Bug]: WebDAV storage health-check uses GET on the base URI → fails (403) on hardened WebDAV servers (Apache Options -Indexes), blocking all edition forms

[GeoHuerta]

What is the bug? (in English)

The WebDAV storage health-check RemoteStorageRequest::checkWebDAVStorageConnection()
probes the storage with an HTTP GET on the profile baseUri (a directory/collection):

$response = $client->request('GET', $profile['baseUri']);

On a hardened WebDAV server where directory listing is disabled — Apache
Options -Indexes, a common and legitimate security setting — a GET on a
directory returns 403. The check then returns false and every edition form
containing a WebDAV upload field is blocked with the error "WEBDAV storage
unavailable", even though the storage is fully functional (file upload, download
and delete all work).

A GET on a WebDAV collection is not the correct way to probe it; a PROPFIND with
a Depth header is. The GET-based check is present on master, release_3_9,
release_3_8 and release_3_7.

Steps to reproduce the issue

Backend: a WebDAV server that returns 403 on a GET of a directory (e.g. Synology
DSM served by Apache with directory listing disabled), while file operations work.

1. Configure a [webdav:default] profile pointing to such a server (baseUri, user,
   password), storage otherwise fully working.
2. In a QGIS project, set an edition form field to "WebDAV" storage type.
3. In Lizmap, open the edition form and try to save a feature with that field.
   -> The form fails with "WEBDAV storage unavailable".

Reproducing the root cause directly with curl (same account, same baseUri):

GET      directory (baseUri)          -> 403
PROPFIND directory, no Depth header    -> 403
PROPFIND directory, Depth: 0           -> 207
GET      a file                        -> 200
PUT / DELETE a file                    -> 201 / 204

So auth, TLS and file read/write are fine; only the directory GET (and a
Depth-less PROPFIND) are refused — which is exactly what the health-check does.

Suggested fix (tested end-to-end on our Synology/Apache backend, form saving works
afterwards):

$response = $client->request('PROPFIND', $profile['baseUri'], ['headers' => ['Depth' => '0']]);

Note the Depth header is required: a bare PROPFIND also returns 403 on this server.

Versions, safeguards, check summary etc

• Lizmap Web Client: 3.9 (Docker image 3liz/lizmap-web-client:3.9)
• WebDAV backend: Synology DSM, served by Apache, HTTPS + Basic auth
• Affected file: lizmap/modules/lizmap/lib/Request/RemoteStorageRequest.php
  (method checkWebDAVStorageConnection)
• Confirmed the same GET-based check exists on master, release_3_9, release_3_8,
  release_3_7.

Check Lizmap plugin

• I have done the step just before in the Lizmap QGIS desktop plugin before opening this ticket. Otherwise, my ticket is not considered valid and might get closed.

Operating system

Ubuntu 24.04

Browsers

Chrome

Browsers version

Version 151.0.7922.173 (Build officiel) (x86_64)

Relevant log output