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

On 14.03.2023 19:30, Sergey Ponomarev wrote:
> Previously browsers directly supported FTP and WebDAV but today they don't.

Well, WebDAV was only supported by Internet Explorer, right?

> 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
> <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/
> <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.

Why 403?

> 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?

That is already allowed by RFC 4918.

> 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
> <http://subversion.tigris.org/xmlns/dav/svn/depth>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
> <http://subversion.tigris.org/xmlns/dav/svn/log-revprops>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/atomic-revprops
> <http://subversion.tigris.org/xmlns/dav/svn/atomic-revprops>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/partial-replay
> <http://subversion.tigris.org/xmlns/dav/svn/partial-replay>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/inherited-props
> <http://subversion.tigris.org/xmlns/dav/svn/inherited-props>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/inline-props
> <http://subversion.tigris.org/xmlns/dav/svn/inline-props>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/reverse-file-revs
> <http://subversion.tigris.org/xmlns/dav/svn/reverse-file-revs>
> DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
> <http://subversion.tigris.org/xmlns/dav/svn/mergeinfo>
> DAV: <http://apache.org/dav/propset/fs/1
> <http://apache.org/dav/propset/fs/1>>
>
> This is too big overhead if it's added for each GET request

Right.

> 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 <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.

...nor servers.

> 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
> <https://lists.w3.org/Archives/Public/w3c-dist-auth/2008OctDec/0026.html>

There we go :-)

> 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://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://example.com>
>
> HTTP/1.1 201 OK
> Content-Type: application/xml+xhtml
> Content-Length: xxx
>
> <html xmlns="http://www.w3.org/1999/xhtml <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 <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.

I would agree that link relations provide the best flexibility here.

> 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.

Note that the "dav" URI scheme does not describe a protocol; use of it
as *locator* does not conform to the definition. The other schemes seem
to be unregistered.

If you think those are useful, it might be good to come up with a
problem statement and a document defining what they mean.

> This is also confusing because I didn't find anywhere that the dav://
> protocol has a schema. Can we have a spec on this?

WebDAV is an application of HTTP. It doesn't need a separate schema.

> Here on IANA said that the dav:// is registered
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> <https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml>
> But not the davs://

Yes, "dav" was registered solely for the purpose for use as XML
namespace name.

> 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
> <https://github.com/stokito/awesome-webdav>
>
>
> Regards,
> Sergey Ponomarev,
> https://github.com/stokito <https://github.com/stokito>

Best regards, Julian

Received on Thursday, 16 March 2023 10:10:07 UTC