Copyright (c) RISC OS Developments 2026. All rights reserved.
SPDX-License-Identifier: CDDL-1.0

# WebDAV review candidate

This Beta 18 copy uses the bundled TLSManager OpenSSL 3.5.8 transport for HTTPS WebDAV. Portable backend tests pass. On the Raspberry Pi at `10.10.0.66`, an authenticated pCloud mount listed its root, created/read/deleted an ordinary file, and recursively round-tripped a five-file application directory. All returned file hashes matched and no companion file was present. The broader native failure matrix and QNAP remain pending. Preserve your tested installation while evaluating this candidate.

## Connect

Choose `WebDAV login...` from the LanMan98 iconbar menu. The login window starts with `https://` in Server and the URL field selected. Enter a local mount name and your account credentials locally. Enter a case-sensitive collection path in Share, or put the complete collection URL in Server and leave Share empty. HTTP is available for local testing; use HTTPS for cloud credentials. `SMB login...` remains a separate menu action.

QNAP: use `https://your-nas:configured-WebDAV-port/` and the shared folder as Share, or the full folder URL with Share blank. Enable WebDAV on the NAS and use its configured port and trusted certificate. See [QNAP instructions](https://www.qnap.com/en-us/how-to/faq/article/connecting-to-webdav-shared-folders-on-a-qnap-nas-in-windows-10).

UGREEN UGOS: the defaults are HTTP port 5005 and HTTPS port 5006. A live UGOS root advertised `Acornstore` but returned 404 for its trailing-slash URL; LanMan98 retries the advertised slashless collection URL after that specific response. The observed HTTPS certificate was self-signed as `UGREEN` with no Subject Alternative Name, so it cannot validate for an IP-address URL. Install a trusted certificate for the hostname used in the URL; certificate checking is not bypassed.

pCloud: the documented endpoints are `https://webdav.pcloud.com` (US) and `https://ewebdav.pcloud.com` (EU). Select the endpoint matching your account region and enter the account email/password locally. See [pCloud WebDAV help](https://help.pcloud.com/article/webdav). On 21 September 2026, an authenticated account mounted through TLSManager on the Raspberry Pi; root listing, ordinary file create/read/delete and recursive application-directory copy/read/delete succeeded. The final candidate also removed two existing test collections after handling pCloud's HTTP 403 response to the trailing-slash DELETE. This is provider/account evidence for that target, not QNAP coverage or the complete failure matrix.

The mount check retries the selected collection root with `Depth: 1` when the normal `Depth: 0` PROPFIND does not identify a collection. Child lookup also retries the parent collection at `Depth: 1` when the direct child probe returns no usable resource, accepting only an exact decoded href match. A controlled host server verifies the reported pCloud pattern: root listing succeeds, direct child lookup returns 404, and the exact child is recovered from the parent listing. Native confirmation still requires the matrix below.

HTTPS requires the bundled `!TLSManager`, OpenSSL 3.5.8 and its packaged Mozilla CA bundle dated 13 August 2026. Certificate-chain and hostname verification, SNI and TLS 1.2/1.3 remain enabled. TLSManager uses `CryptRandom_Block` for entropy and does not alter AcornSSL or the system certificate store. Native transport currently resolves IPv4 hosts. A chain outside the packaged trust store fails closed; there is no automatic certificate-check bypass.

## Behaviour and limits

- Mounting and browsing use PROPFIND; files use GET and PUT; directories use MKCOL; rename/move uses MOVE; deletion uses DELETE.
- Collection readback and deletion use canonical trailing-slash URLs. If the initial slashless MKCOL returns a redirect after creating a folder, as reported with pCloud and QNAP, LanMan98 does not follow or repeat it: creation succeeds only when a direct request to the canonical URL confirms the collection.
- pCloud can reject a collection DELETE at the canonical trailing-slash URL with HTTP 403 while accepting its slashless equivalent. LanMan98 retries that equivalent form only for the identified pCloud endpoints and only after the first request is explicitly rejected.
- When an advertised collection returns 404 only for its trailing-slash URL, LanMan98 retries the equivalent slashless URL. This is bounded to 404 and supports the observed UGREEN UGOS behavior without masking permission, authentication or server errors.
- Basic authentication is implemented. Digest, OAuth, automatic redirects and WebDAV LOCK are not implemented. This is not a claim of compatibility with every cloud service.
- A whole file is staged on local scratch storage for random reads/writes; allow sufficient local space. Changes upload on close. The existing filesystem limit is 2 GiB minus one byte per file.
- GET and PUT bodies use a 32 KiB heap buffer. A new file is created by its final conditional PUT, avoiding the old empty PUT, readback and empty GET sequence. Servers returning a redirect, 405 or 501 for optional metadata updates are remembered for the mount; redirects are not followed. Connection reuse and resumable/chunked uploads are not implemented.
- Updating an existing file requires a strong ETag. A remote edit conflict rejects the upload and preserves the local cached edit while its handle remains open. This is not durable crash recovery; do not force unload during a conflict.
- Servers that support the custom dead properties can retain RISC OS metadata. Otherwise server timestamps/default attributes are used; changing readonly attributes can fail explicitly. Metadata support is checked by readback.
- RISC OS filetypes are retained in reversible `,xxx` wire-name suffixes and hidden from the RISC OS display name. WebDAV mounts keep this enabled because generic cloud storage has no native RISC OS catalogue. Long mixed-case path components are preserved and do not use the DOS 8.3 mapper retained for old SMB servers.
- FileSwitch may create a sized zero placeholder, close it, reopen it for the real bytes and only then supply the filetype. LanMan98 retains that provisional file in its local cache across the reopen and uploads only the final typed name. The provisional Text name is never created remotely, preventing pCloud's version selection from producing a zero-filled companion.
- Free-space reporting requires server quota properties; unsupported quota returns an error instead of invented capacity.
- XML responses are bounded to 16 MiB and 262144 nodes, with nesting limited to 64 levels. Network operations have cooperative timeouts.

Protocol reference: [WebDAV RFC 4918](https://www.rfc-editor.org/info/rfc4918/).

Whole-file save/create errors cancel their internally-owned local staging cache without retrying PUT, resizing back, or deleting the remote object during cleanup. The caller receives the error and still owns its source data. A failed create can therefore leave an empty or already-committed remote object; inspect it before retrying. This differs from an ordinary open file whose rejected close retains its cache for retry. Native FileSwitch/application error handling still requires hardware testing.

The former AcornSSL retry-stack failure and `SWI &207C24 not known` path are no longer part of HTTPS WebDAV in Beta 18. LanMan98 retains TLSManager operation state outside the cooperative thread stack, and TLSManager owns the OpenSSL connection until close.
