WebDAV

The WebDAV authoring interface exposes each Pagelove site as a standard WebDAV mount. Any filesystem client that speaks WebDAV can browse and edit content directly.

When to reach for it

Use WebDAV for file-level authoring — uploading assets, reorganizing directories, or editing documents with desktop tools. Each site has its own mount URL. Credentials are configured in the Pagelove control panel.

Live site

The WebDAV mount represents the live site. Pagelove modifies the DOM in place, so another user or an API call may update a document between the time it is read and the time it is written back. The author is responsible for coordinating concurrent changes.

Directory listings and revalidation

Every directory has a version tag (an ETag). A client that already has a copy of a listing can send that tag back on its next PROPFIND as If-None-Match; if nothing in the directory has changed, the server answers 304 Not Modified with an empty body and the client reuses what it has.

The tag belongs to the question you asked, not just to the directory. Depth: 0 asks for the directory's own properties; Depth: 1 (the default when no Depth header is sent) asks for the directory and everything directly inside it. Those are two different answers, so they carry two different tags. Sending a Depth: 0 tag with a Depth: 1 request returns the full listing rather than a 304 — a listing is never answered with "nothing changed" on the strength of a stat.

The tag appears both as the ETag response header and as the <D:getetag> property of the directory's own entry in the multistatus body; the two always agree. Responses also carry Vary: Depth, so a caching proxy placed in front of the authoring server keeps the two depths apart.

A directory's tag changes whenever a child is added, removed, or edited. PROPFIND on a single file is currently always answered in full — If-None-Match is not yet honoured there, so don't rely on never receiving a 304 for a file PROPFIND.

When something goes wrong

An error response carries an HTML document describing what happened, not just a status code. It is marked up so a program can read it:

<article itemscope itemtype="https://pagelove.org/Error">
  <meta itemprop="status" content="422">
  <meta itemprop="kind" content="UntranslatableWrite">
  <div itemprop="type" itemscope
       itemtype="https://dombase.pagelove.team/ns/error/UntranslatableWrite"></div>
  <p itemprop="message">…</p>
</article>

The kind names the specific failure, and the nested item repeats it as a type you can match on. Those names are the same ones the HTTP interface uses, so a client that already understands errors from one interface understands them from the other — the server never invents a name of its own here.

When a write is refused by the shared pipeline, the pipeline's own error document is included unchanged under a detail property, so you get its full description rather than a summary of it.

The status code tells you what to do about it, and it is worth distinguishing two that look similar:

• 404 means the file you addressed is not there.
• 500 means the server failed — including when the server could not load the site's schema. A schema problem is never reported as 404, because that would say your file had been deleted when it had not. A syncing client should treat 404 as "this file is gone" and 500 as "try again later", and the server will not confuse the two.

Other codes you may see: 409 when a write conflicts with a concurrent change, 400 for a path the server will not accept, 422 when the content does not satisfy the site's schema or constraints, 503 when the storage layer is briefly unavailable and the request can be retried, and 507 when the request exhausted its allowance.

See also

• Reading and writing — fragment-level reads and writes via HTTP
• Permissions — authorization rules that apply to WebDAV operations