Open WebDAV directly from a browser. How to let know that the resource have a dav version?

Previously browsers directly supported FTP and WebDAV but today they don't.
This is critical from a UX and security perspective and should be
re-implemented.
Typical scenario: as a user I wish to download multiple files e.g. photos
by just selecting them without need for tar/zip them on a server and
without needing any arhivers on my computer.
I need this for self hosting users who today have NAS, Raspberry PI and
even routers with USB disk. And they need some basic UI that works out of
the box.

I created a browser extension for Chrome and Firefox
https://github.com/stokito/webdav-browser-extension
It should be user friendly and it must detect a WebDAV share itself and
render a UI for it.
The problem is that it's not possible to know if the current
resource/folder has a dav version without making an additional OPTIONS call.
So if a user opens https://example.com/webdav/ just in a browser it may see
either a blank 403 page or a dir listing/index page with 200 OK.
Currently I implemented some heuristic and when the 403 error returns then
the plugin will try to make an OPTIONS call and check for the DAV header.
I hope that the 403 errors don't occur so often and false checks won't be a
problem.
But if the directory has an index.html or a generated directory listing
then the plugin simply doesn't even have that simple heuristic.

This is something that can be solved quite easily on a server level by just
adding a header to a folder to let you know that the folder has a dav
version.
We already have a DAV header as a response to OPTIONS then what if we can
recommend to return it in response to a GET request?
If won't harm anything and can be parsed by the same function.

The problem that I see is that the DAV may be quite big. E.g. is the
directory is an SVN repo then you'll get:
DAV: 1,2
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
DAV: http://subversion.tigris.org/xmlns/dav/svn/atomic-revprops
DAV: http://subversion.tigris.org/xmlns/dav/svn/partial-replay
DAV: http://subversion.tigris.org/xmlns/dav/svn/inherited-props
DAV: http://subversion.tigris.org/xmlns/dav/svn/inline-props
DAV: http://subversion.tigris.org/xmlns/dav/svn/reverse-file-revs
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: <http://apache.org/dav/propset/fs/1>

This is too big overhead if it's added for each GET request

Another issue is that the folder MAY have a dav version but the HTML is
preferable e.g. it has thumbnails and styles and not just a default
generated directory listing.
So ideally we need to set some priority between html and dav versions.
While I wrote this I remembered about MS-Author-Via header that from its
description looks like it has a similar intention.
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wdvse/c99757e4-ea88-49a6-bae5-c6297a024c99

But I never saw how it should work in real life. Maybe someone can add
details on how the header was used? Anyway that header had some useful
intent that should be considered to be included into the spec.
What if we add the header to a spec specifically to use as a suggestion to
which UA to use: browser or a file manager (or something else like an IDE?).

The header may be added not only to folders / but to specific files. E.g.
if I opened a text file directly by a link then the Author-Via header may
tell my browser to perform OPTIONS and to see if I can edit or version
control supported.

One other minor problem is that the dav folder may be read only but users
will anyway see Edit buttons in UI. This is something that can be solved
with ACL but the spec is hard to implement and looks like not so often
supported by clients.
Maybe this also can be somehow solved by just the header with some
additional ro attributes. Plainly stupid but covers basic needs.
Maybe just OPTIONS without PUT but basically if admin can edit then it
won't see the edit controls. This is not that important but something that
may be useful.

I can also just try to use other heuristics like a dav subdomain, folder
name /dav/ or NextCloud specific /nextcloud/remote.php/dav/files but still
some simpler and more general solution would be great.

I found some interesting idea was proposed by Julian Reschke "Mapping DAV
link properties to HTML/Atom/Http link relations"
https://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html

1) Use in HTTP Link Header

A server could expose the property value in an HTTP response header,
independently of WebDAV:

HEAD /foobar HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/plain
Link: </versions/foobar/1>; rel="DAV:checked-in"

2) Response bodies of WebDAV requests that affect the set of links could
be made more useful, such as in:

VERSION-CONTROL /foobar HTTP/1.1
Host: example.com

HTTP/1.1 201 OK
Content-Type: application/xml+xhtml
Content-Length: xxx

<html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <title>Resource put under Version Control</title>
   </head>
   <body>
     <p>
       The resource has been put under version control; the
       version history is located at <a rel="DAV:version-history"
href="/histories/123">/histories/123</a>, and the initial version is <a
rel="DAV:checked-in" href="/versions/456">/versions/456</a>.
     </p>
   </body>
</html>


This is something related to SVN. But the Link header looks similar to the
Author-VIA that I proposed before. And looks more natural.
Also usage as an anchor rel may help to create nice looking webdav links.
Something like

<a href="http://dav.example.com/photos" rel="DAV">My Photos</a>

The advantage would be that the link is working in the browser but the
"rel=DAV" can be just a hint for my plugin to open the directory as webdav
UI.

But still what if I need to directly specify dav in the address bar?
The pugin should also support all links with webdav:// webdavs:// (KDE)
dav:// davs:// (GNOME) schemas and open them directly in the file browser
UI without any heuristic guesses.
This is also confusing because I didn't find anywhere that the dav://
protocol has a schema. Can we have a spec on this?
Here on IANA said that the dav:// is registered
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
But not the davs://

Maybe even dav+http:// or web+dav:// (similarly to web+ap:// for web-based
ActivityPub) would be something that is more appropriate.

BTW the svn:// is widely supported and basically the Subversion may be used
to work with a dav share. In fact this is kind of an extension of dav
protocol. So maybe just use it?
The SVN looks not popular anymore but still it's an URI schema that does
not necessarily represent a protocol similarly like https link may
use http2.
But still, reusing an existing schema is not such a weird idea.


I would appreciate any comments and thoughts.


P.S. Check the Awesome WebDAV list https://github.com/stokito/awesome-webdav


Regards,
Sergey Ponomarev,
https://github.com/stokito