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

Thanks! I'm not familiar yet with caldav but it looks like this is
something similar. Is it used anywhere? I wish to test it somehow and see
it in a demo.
Meanwhile I came to the idea that basically the header discovery may be not
needed. I just checked and it turned out that almost all cloud
providers have dav. or webdav. subdomain or URL prefix. And
Nextcloud/ownCloud use something different e.g. /remote.php/dav/files/
Exceptions are very rare and usually that's a url with IP address in local
network. So the heuristic should work reliably.
Now I'm not sure how important it would be to have a dav detection by
header.

Off topic:
There is also mention of  RFC6578 Collection Synchronization
https://www.rfc-editor.org/rfc/rfc6578.
It looks like it may be useful for file syncing like Dropbox.
Does anyone know if it's used anywhere? Maybe some backup tools.

I wanted to have something similar for RSS. My blog engine can produce RSS
but also can read RSS from other instances of my friends. Some kind of a
cheap ActivityPub. And I wished to fetch only added or updated blog entries
since last check.
Maybe I can use the spec with a few small modifications of the RSS
generator.




On Sun, Mar 26, 2023 at 11:21 PM Michael Douglass <mikeadouglass@gmail.com>
wrote:

> This looks very much like
> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/
>
> This was proposed to allow advertisement of a more efficient form of
> subscription rather than repeated download of an ics file.
>
> I've no idea why it hadn't occurred to me that it would make sense on a
> web page as headers.
> On 3/26/23 13:13, Sergey Ponomarev wrote:
>
> Thank you, Julian,
> So there is no official protocol schema. But unofficially the dav:// and
> davs:// become more supported e.g. in GNOME Files (Nautilus) and soon in
> KDE Dolphin.
> I also created a ticket for Nautilus to support the webdav:// schema just
> because users may not remember a proper schema. But it may take a lot of
> time for them to implement.
>
> Interestingly, just the http:// should also work for Gnome Files but it
> looks broken. Windows mount works only by the http://
> It's a good question if the separate protocol schema is needed. Even if a
> user clicks on the http:// link the browser itself may try to detect the
> dav folder and render it as a folder.
> Still having an explicit protocol would be better. So you add it somewhere
> in spec or somehow confirm that you are fine with usage of dav:// and
> davs:// as a schema?
>
>
>
> Speaking about some header added to all GET request to let know about
> ability to watch the folder as dav.
> We have few options:
> 1. DAV header. It would be easier to implement because it's already added
> for OPTIONS. It can be big for SVN or something like that but this is a
> rare case and anyway HTTP2 HPACK should solve the problem.
> 2. Link is less obvious and not described in the dav spec so it needs for
> more work.
> 3. Alt-Svc is also something that may be used. Not sure if this would be a
> proper usage.
>
> The preferable view as webpage or as a webdav may be an overcomplication.
> Maybe user's browser have a dav less useful that automatically generated
> directory listing. Most time I expect oposite. Here a browser can show a
> button on top of the page and propose to a user to decide and remember it's
> choise. This would be a simplest solution and if needed we may back to this
> on future.
>
> Read only view also doesn't have a good solution so let's keep it out of
> the scope. Only ACL or sonething like that can solve the problem.
>
>
> So to summarize: does anyone have any ideas or concerns about using the
> DAV header on GET requests?
> If no then I'll implement it in my browser extension and I'll ask existing
> servers to add the header.
>
> Please vote with + or -
>
> Thank you
>
>
> --
> Sergey Ponomarev <https://linkedin.com/in/stokito>,
> stokito.com
>
>

-- 
Sergey Ponomarev <https://linkedin.com/in/stokito>,
stokito.com