Crate io_webdav 

io-webdav

I/O-free WebDAV client coroutines built on io-http: every network exchange is a resumable state machine emitting read and write requests instead of performing I/O itself. The caller owns the socket and pumps the coroutine with the bytes it read, whatever the runtime (blocking, async, in-memory tests). The client feature ships a ready-made std-blocking pump for callers who just want a working client.

Layout: one folder per RFC

The source tree mirrors how the WebDAV specifications are split, one module per RFC. rfc4918 implements the WebDAV core: the PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, DELETE, GET, PUT, OPTIONS and REPORT requests, the multistatus response parser, the rfc4918::WebdavAuth modes and the low-level send coroutine every higher request builds on. rfc4791 covers CalDAV: calendar collections and calendar object resources (items), with calendar home-set discovery. rfc6352 covers CardDAV: address book collections and contact cards, with address book home-set discovery, batch multiget and ETag-only enumeration. rfc5397 discovers the current user principal, the entry point of the discovery flow. rfc6578 adds collection synchronization: the sync-collection REPORT and its sync tokens.

Two modules span the RFC modules and therefore live at the crate root: coroutine defines the coroutine contract every state machine implements, and the optional client module (client feature) is the std-blocking pump: a light client wrapping any stream you opened yourself, or a full client opening the TCP/TLS connection itself when one of the TLS features is enabled.

The coroutine contract

Every coroutine implements coroutine::WebdavCoroutine: a resume method taking the bytes read since the last step and returning either an intermediate yield or a terminal completion. Standard coroutines yield the shared read and write requests of coroutine::WebdavYield; the redirect-aware discovery coroutines declare their own rfc4918::coroutine::WebdavRedirectYield, surfacing a 3xx response to the caller as a redirect request instead of following it, so the caller decides whether to reconnect to the new authority and retry. The webdav_try macro chains an inner coroutine step inside an outer resume, re-yielding and short-circuiting like the question mark operator.

Conventions

The crate is no_std with alloc; std only enters behind the client feature. Every public item carries the bare Webdav prefix, the protocol not being version-scoped. Logging follows the library rules: state changes at debug level, in-process steps and data dumps at trace level.

Modules

clientclient

Standard, blocking WebDAV client

coroutine

Generator-shape coroutine driver. Mirrors core::ops::Coroutine: a Yield associated type for intermediate progress, a Return for terminal output, and a two-variant WebdavCoroutineState.

rfc4791

RFC 4791: Calendaring Extensions to WebDAV (CalDAV).

rfc4918

RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV).

rfc5397

RFC 5397: WebDAV Current Principal Extension.

rfc6352

RFC 6352: CardDAV, vCard Extensions to WebDAV.

rfc6578

RFC 6578: Collection Synchronization for WebDAV.

Macros

webdav_try

Coroutine ?: forwards Yielded (via Into), short-circuits on Err (via Into), evaluates to the inner Ok value.