WsgiDAV: a WebDAV server you can also mount inside your own WSGI stack

A WebDAV server, a WSGI library, and a middleware stack

WsgiDAV is described as a generic and extendable WebDAV server written in Python and based on WSGI, and the three ways it can be used are worth separating because they have different consequences.

The first is as a stand-alone server. It is a command line script that runs on Linux, macOS and Windows, with SSL support, and it is a real WebDAV implementation, not a file browser with a WebDAV veneer. The quick start is two commands:

pip install wsgidav cheroot
wsgidav --host=0.0.0.0 --port=80 --root=/tmp --auth=anonymous

The second is as a library. WsgiDAV implements the WSGI protocol and can be run behind any WSGI compliant web server, which means it can be mounted inside an application that already has a web server, a router and a process manager, instead of adding a second daemon.

The third is the architectural claim that ties the two together. WsgiDAV is implemented as a configurable stack of WSGI middleware applications, and its open architecture is what allows WebDAV services to be integrated into your project. The typical use cases the documentation gives are exposing data structures as virtual, editable file systems, and allowing online editing of MS Office documents. That second one is the reason WebDAV still exists: a desktop Office client can open a document over WebDAV and lock it while it is being edited, and a plain HTTP file share cannot do that.

The WebDAV protocol is RFC 4918, and the project's own note on the WebDAV being a superset of HTTP is worth reading twice: it means the same server also serves ordinary web traffic, so it is a performant, multi-threaded web server with SSL support as well as a WebDAV endpoint.

The licence history is unusual. WsgiDAV is a refactored version of PyFileServer 0.2 by Ho Chun Wei, and the documentation records that Chun gave his approval to change the licence from LGPL to MIT for this project.

The startup log tells you exactly what you have exposed

The quick start output is the most instructive part of the documentation, because the server tells you what it has done and what it thinks of it.

10:54:16.597 - INFO    : WsgiDAV/4.0.0-a1 Python/3.9.1 macOS-12.0.1-x86_64-i386-64bit
10:54:16.598 - INFO    : Registered DAV providers by route:
10:54:16.598 - INFO    :   - '/:dir_browser': FilesystemProvider for path '...' (Read-Only) (anonymous)
10:54:16.599 - INFO    :   - '/': FilesystemProvider for path '/tmp' (Read-Write) (anonymous)
10:54:16.599 - WARNING : Basic authentication is enabled: It is highly recommended to enable SSL.
10:54:16.599 - WARNING : Share '/' will allow anonymous write access.

Three things to notice. The first is that the DAV providers are listed by route with their path, their access mode and their realm, so a share configured as read-only and a share configured as read-write are distinguishable at a glance. The second is that the built-in directory browser is registered as its own route, `/:dir_browser`, and it is read-only, which means you get a human-readable listing without that listing being writable.

The third is the two warnings, and they are the reason this example is not a production configuration. Basic authentication is enabled and the server recommends SSL, and the root share allows anonymous write access to `/tmp`.

The authentication options are more than anonymous. The python-pam library is an extra requirement if pam-login authentication is used on Linux or macOS, and the invocation for that is:

pip install wsgidav[pam]
wsgidav --host=0.0.0.0 --port=8080 --root=/tmp --auth=pam-login

The `requirements.txt` at the root of the repository shows the full set of runtime dependencies, and it is worth reading for what they imply. `defusedxml` is there for XML parsing, which is not a detail: WebDAV is an XML protocol and a naive XML parser is a denial of service waiting to happen. `PyYAML` and `json5` are for configuration, `Jinja2` for the directory browser templates, `passlib` and `bcrypt` for password hashing, and `python-pam` for the PAM integration.

A sample configuration file, and Docker for the quick share

The repository ships a `sample_wsgidav.yaml` at the root, and the tool runs without a configuration file at all, as the quick start shows. The message printed in that case is Running without configuration file, which is a useful piece of information to have in the log.

YAML is the configuration format, with `json5` also accepted for the same purpose, and the configuration is where the provider list, the authentication domain, the middleware stack and the per-share options live. The directory structure of the repository mirrors the module layout, with the `wsgidav/` package containing the server, the DAV provider implementations and the samples.

For the case where you just want a share, the Docker route is the shortest. The image is described as experimental, and it exposes a local directory using WebDAV:

docker pull mar10/wsgidav
docker run --rm -it -p 8080:8080 -v /tmp:/var/wsgidav-root mar10/wsgidav

The compose file in the repository is the same idea expressed as a service, with a `./wsgidav_data` volume mounted at `/var/wsgidav-root`, port 8080 published, and `restart: always` on a bridge network named `local`.

Windows users have a third route. The project offers an MSI Installer in the assets section of the GitHub releases, or `winget install wsgidav`.

The fact that there are four ways to install the same server, pip, an MSI, Docker and as a library behind someone else's WSGI server, tells you something about the audience. This is a tool for people who already run Python web servers, and the packaging choices are aimed at each of the places such a person might work.

The middleware stack is the extension point, and the tests are organised around it

The architectural description, a configurable stack of WSGI middleware applications, is not a slogan. It is how the project is organised, and it is what makes the library mode useful.

When WsgiDAV runs behind another WSGI server, the DAV handling is a WSGI application that you mount at a path, and the middleware stack is what sits between the outer server and the DAV provider. That means the pieces that normally are hard to get right in a hand-rolled WebDAV implementation, the request parsing, the method dispatch, the lock handling, the response generation, are all separate layers that can be reordered, replaced or extended with your own code.

The property manager is one of the clearest examples. The coverage configuration in `pyproject.toml` omits specific files from the measurement, and two of them are `wsgidav/prop_man/couch_property_manager.py` and `wsgidav/prop_man/mongo_property_manager.py`. Those are WebDAV property backends, and the fact that the maintainer excludes them from coverage rather than testing them properly is a fair signal: they are the optional extras, the CouchDB and MongoDB backends for storing dead properties, and the core filesystem provider is the supported path.

The test setup is conventional and thorough for a project of this age. Pytest is configured with the test paths pointing at `tests/*.py` and a `benchmarks` marker for the slow benchmarks, the coverage source is the `wsgidav` package with the optional backends and the samples omitted, and there is a `tox.ini` for the test matrix, a `Pipfile` with a lock for the development environment, and a `requirements-dev.txt`. The `mypy.ini` at the root and the ruff configuration in `pyproject.toml` are the type checking and linting story, with ruff running bugbear, pycodestyle, pyflakes, flake8 logging format checks, pyupgrade, print checks and isort.

The ruff configuration has a detail that shows the project's compatibility policy. `target-version` is `py38` even though the comment above it says support Python 3.10+, and the ignore list explains why: UP006 and UP007 are ignored because the old typing syntax is needed for Python 3.9, which means the code stays importable on the older interpreters the project still supports.

Where WsgiDAV is the wrong choice

The first case is a file server that has to be hardened for the open internet. This is a general-purpose WebDAV server with pluggable authentication, and the configuration surface is rich, but nothing in the documentation describes per-user quotas, audit logging, virus scanning of uploads, rate limiting, or a multi-tenant isolation model. A share where strangers can upload files is a different problem from a share for a handful of colleagues, and the second is what this tool is good at.

The second case is a team that wants a modern sync protocol rather than WebDAV. WebDAV locking is still the mechanism that lets a desktop application lock a document, and that is still the reason to run it, but for a consumer-facing product the expectation is now a sync service with a modern client, and this is a protocol from 2007.

The third case is a Windows or macOS user who wants a file share and does not want to run a Python server. WsgiDAV is cross-platform and there is an MSI installer, but the friction of installing a Python application to move files around a network is real, and the operating system already has sharing built in.

The fourth is a codebase already built on a different WebDAV implementation, where a second one is added for a subset of routes. The middleware stack makes that possible, but it also means two servers with two configuration surfaces and two sets of credentials.

On version numbers, there is one thing to check before you pin. The documentation states that release 4.0 introduces some refactorings and breaking changes, and points to the change log for details. The current release is 4.3.5, published 2026-06-27, with 4.3.4 from 2026-05-24 and 4.3.3 from 2024-05-04, and the last push was on 2026-10-08.

Editorial conclusion

WsgiDAV fits a Python team that needs WebDAV semantics, directory browsing or online editing of Office documents over an existing WSGI stack, and it fits a homelab or small office that wants a file share with WebDAV and no extra daemon to install. It does not fit a deployment that needs a hardened, multi-tenant file server with per-user quotas and audit logging. Before you expose it, read the startup warnings the server prints, because running with anonymous write access and basic authentication over plain HTTP is exactly the configuration the tool warns against, and it is also the configuration in the quick start example.

Frequently asked questions

Official sources

1. License: MIT
2. mar10/wsgidav on GitHub
3. Project website
4. README
5. Releases