This is in response to https://git-annex.branchable.com/special_remotes/webdav/#comment-cd53cf0276427cc924ae66553985ec5c where httpalso is recommended as an approach to get read-only access to a webdav remote.
A use case not possible with that approach is authenticated read-only access. According to http://git-annex.branchable.com/special_remotes/httpalso/#comment-4f41f401d4b0133d2ef12912b9217e44 this is not supported right now, but could be added.
Weighing the two approaches (read-only webdav vs authenticated httpalso), it appears that only the read-only webdav is compatible with git-remote-annex, because a user would need to declare one special remote (configuration) to use for cloning.
It would be great to have authenticated, read-only access to webdav shares. Thanks in advance for considering!
I'm not sure I'd trust an old comment of mine to reflect whether httpalso supports http authentication. From what I can see, without trying it, it will use git-credential to prompt for password when receiving a 401 response, the same as all other parts of git-annex that download urls do nowadays.
Re git-remote-annex, I see your point though. Since it does set up the remote when cloning, and webdav remote setup calls involves creating and deleting a test file, the user needs write access currently. (Whether that test file is worth it doing at all, I'm on the fence about. It seemed like a good idea way back when.)
I think that, rather than needing readonly=true, enableremote of a webdav special remote should just assume it exists and not test write access to it. Then it will work with readonly access. I've implemented that.
And I've made git-remote-annex on git clone do an enableremote, rather than an initremote. That should make it work with a readonly webdav special remote.