[WAGON-583] WebDavWagon and tests do not adhere to RFC 4918

[jira-importer]

Michael Osipov opened WAGON-583 and commented

While working on release 3.4.0 I have noticed several issues (non-exhaustive) with the WebDavWagon:

• On a PUT request 409 is ignored when parent collections do not exist.
• Redirects on MKCOL are competely ignored because not the relocation is not passed to mkdirs(), but the original path.
• Status code management from MKCOL are incomplete.
• Most tests treat WebDAV like HTTP which is wrong. MKCOL requests are answered with 404.

They are likely many other issues I did not discover or already forgot. A serious amount of time needs to be invested to make this Wagon decently compatible with real world servers and along with real world tests.

Therefore, I propose following options:

• Bring this on par with the regular HttpWagon
• Deprecate in 3.x and remove in 4.0.0
• Mark it especially as unmaintained (abandoned) from 3.x

---

Affects: 3.3.4

Issue Links:

• WAGON-617 Deprecate Wagon WebDAV Provider

[jira-importer]

Michael Osipov commented

Still valid.

[slachiewicz]

Partial progress worth recording against the original list, so the remaining work is clear.

Moved since 2020:

• Redirects on MKCOL are completely ignored. WagonRedirectStrategy now includes MKCOL among the methods it follows redirects for. The comment there is honest about the limit: it covers "the most basic case where the redirection relocates to another collection which has an existing parent collection". So improved, not closed.
• The provider no longer depends on jackrabbit-webdav at all (Replace the jackrabbit-webdav dependency with the WebDAV requests actually used #898). The three requests it actually issues — MKCOL, PROPFIND, HEAD — plus multistatus parsing now live in the provider, which makes the RFC 4918 behaviour visible and changeable in one place rather than spread across a third-party library.
• MKCOL status handling is incomplete. Give MKCOL the status vocabulary RFC 4918 defines #983 (wagon-3.x) and Give MKCOL the status vocabulary RFC 4918 defines #984 (master) give it the vocabulary RFC 4918 section 9.3.1 defines: 201 is a collection we created, 405 one that was already there, 409 says an ancestor is missing and is the only reason to step further back. Two defects fell out of the old "everything else means missing ancestor" reading — a 403 or an authentication failure walked up to the root and then failed naming a path that was never the problem, and a 405 on the way down failed the upload whenever a collection appeared underneath us.

Unchanged:

• PUT returning 409 when parent collections do not exist is still not handled. In practice AbstractHttpClientWagon calls mkdirs before the PUT rather than reacting to a 409, so the case is largely covered, but the reactive path is still missing.
• The tests still exercise WebDAV through the HTTP test base. This is the last item on the original list.

On deprecating the provider instead: I no longer think that is the right call, and the reason is a dependency that has already gone. The case for removal rested on this provider pinning the stack to HttpClient 4 through jackrabbit-webdav. It does not any more — the module's compile dependencies are wagon-http-shared, plexus-utils, slf4j-api, httpclient and httpcore, with no Jackrabbit at all. It reaches HttpClient only through wagon-http-shared, exactly like wagon-http, so it migrates with the rest of the codebase rather than blocking it.

The cost of removal is also higher than it first looks. maven-build-cache-extension can drop it: apache/maven-build-cache-extension#526 serves a dav: cache through the resolver HTTP transport, which does the MKCOL traversal itself under supportWebDav. maven-site-plugin cannot — site deployment looks a Wagon up by protocol rather than going through the resolver, so no transport flag helps it. Removing the provider deletes dav: site deployment (MSITE-750) with no drop-in replacement; removing even the test dependency makes three of its tests fail with Cannot find wagon which supports the requested protocol: dav.

So the sequence would have to be the reverse of the original proposal: give maven-site-plugin a WebDAV path that needs no Wagon first, then retire. My suggestion is to keep the provider, finish the remaining item above, and treat it as an ordinary module in the HttpClient 5 migration.

One number I do not have: how many people still deploy sites over dav:. No Apache Maven project does — there is no dav: URL in any distributionManagement across the estate. If that holds for the wider user base, retirement becomes reasonable again, and dev@ is the place to ask.