Skimming the source, I can see an Evolution "workaround" for Fastmail's Cyrus server in https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/backends/caldav/e-cal-backend-caldav.c?h=gnome-3-28&id=252f5be5e2fb7ae235e99ec08d347e16beb19e7a#n118. They don't [rightly] permit PUTs on collections either. Don't know what they do with POST, but it too is not the right thing to check for. ;)

For the record, POST on collections is also undefined:
RFC 4918 Section 9.5:
> 9.5.
> POST for Collections
> Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.

Thanks for a bug report. Both PUT and POST are not issued on the collection itself, they are always issued on a resource, either existing or new.

The OPTIONS is used to get both DAV and Allow headers, where the 'Allow' is used as a "shortcut" to determine write-ability of the resources in that collection. This works on many servers (I'd say most, but I do not know as that many, neither I have access to all servers out there; the behaviour had been tested with DAViCal, Google, ownCloud, Yahoo!, Zimbra, iCloud, Radicale and Yandex servers, plus some other providers with different versions of ownCloud/nextCloud, mostly).

Ideally, the write-ability might be determined through ACL [1], but not all servers support it.

An option would be to have the CalDAV calendars (and CardDAV books) always set as writeable and let the server fail the request when needed, which would work and may make things more correct with respect of per-resource ACL, but then I'm afraid a bug about "true read-only collections being treated as writeable" would be filled by other users.

When I look into an example of the OPTIONS request being issued on a collection
at [2], I see the Allow header is populated both with POST and PUT. I know this section is not authoritative, but I didn't find much documentation about the OPTIONS request, and specifically about the Allow header, either. 

[1] https://tools.ietf.org/html/rfc3744
[2] https://tools.ietf.org/html/rfc4791#section-5.1.1

> The OPTIONS is used to get both DAV and Allow headers, where the 'Allow' is used as a "shortcut" to determine write-ability of the resources in that collection.

Like I said, it's fine to use OPTIONS as a shortcut, but the shortcut is used on the wrong path. The _collection_ need not be PUT nor POSTable and that's why you're seeing Fastmail et alii not supporting this. As I alluded to before, I don't know why Fastmail happens to support POST, but it's certainly not required and Evolution must not depend on a idiosyncrasy of an API. If we go for OPTIONS, we must do them on the event resource path. 

> When I look into an example of the OPTIONS request being issued on a collection
at [2], I see the Allow header is populated both with POST and PUT. I know this section is not authoritative, but I didn't find much documentation about the OPTIONS request, and specifically about the Allow header, either. 

True, that example does contain PUT or POST, but that's a side effect of a DAV being on top of HTTP. A DAV compatible resource can just as well do regular REST things with POSTs or PUTs. I'd say having irrelevant things in spec examples is misleading though.

Fact is, checking for PUT or POST on the collection resource will not work as there's nothing for the server to do on PUT and POST from a DAV perspective. Unless you've spotted something in the spec that I haven't, that is. I work on a CalDAV server and Thunderbird, Evolution, MacOS Calendar and iOS Calendar so far work fine without nor do any PUTs or POSTs on collections in the first place.

Addition for my last statement: Evolution works only once you sniff the user-agent and add "POST" to the collection's OPTIONS response's Allow header. AFAICT it never really makes POSTs, which itself is a bit of a giveaway that something is wrong here. :)

CalDAV in evolution-data-server doesn't use POST, no. It uses PUT, but never on collection, only on resources.

Trying to ask on OPTIONS or ACL on a single resource is also wrong, because the ACL can be applied per resource, not only per collection, thus one gets similarly wrong result, not talking that "which resource should I use the best to determine whether I can write into the collection? And what if there is no resource in this collection at all?".

When you look into the WebDAV backend in addressbook (it's CardDAV, but for historical reasons it's named WebDAV on the disk), it mentions that Google and iCloud servers return 404 for OPTIONS issued on addressbook collections. Their CalDAV implementation works differently.

It seems that the OPTIONS can be used with an asterisk as the resource:
https://tools.ietf.org/html/rfc7231#section-4.3.7
but I do not know whether it'll work for the servers. That can be added as an additional method to determine write-ability of the book/calendar.

I don't know. OPTIONS on a non-existing event resource sounds a pretty good writeability indicator to me as you need to be able to PUT it to create an event, but if you're saying some servers respond with 404s for OPTIONS on non-existing resource, that in itself sounds like a spec violation. What do you think we should do?

I can ping Neil from Fastmail to enlighten us what they do with POST --- maybe it's accidental -- in which case they may remove it as well and Evolution would again stop working the way it wasn't working the CalDAV server I'm implementing. I solved it specifically for Evolution with User-Agent sniffing, but I'm sure we all agree that's not a sustainable solution for interoperability.

Ah, OPTIONS with a star seems an interesting corner of the spec, but I don't think it applies. We do want to get the OPTIONS of a particular path, as the server as a whole need not support the "calendar-access" DAV protocol, or DAV itself, for that matter.

(In reply to Andri Möll from comment #6)
> OPTIONS on a non-existing event resource sounds a pretty good
> writeability indicator to me as you need to be able to PUT it to create an
> event,

No, the 4.3.7 of RFC 7231 says the OPTIONS should be requested on a resource, which I somehow understand on existing resource. The 404 is a logic response when trying to get OPTIONS on something that doesn't exist.

> but if you're saying some servers respond with 404s for OPTIONS on
> non-existing resource, that in itself sounds like a spec violation.

No, I said on existing collection (comment #5), not on a resource.

The asterisk sounded to me like a way to get what we want, like when being used on this URL:
   https://www.example.com/dav/me/calendar/*
then I'd expect to get the same as I currently get with
   https://www.example.com/dav/me/calendar/
on all those servers I named at comment #2. Unfortunately, when I re-read the 4.3.7 section I'm less convinced it would be it. I also tried with DAViCal and it does return "404 Not Found, No collection found at that location." when I try the OPTIONS with a URL ending with the asterisk. I agree with them.

By the way, I do not understand your point here. I do not know what the problem is to return also PUT in the OPTIONS Allow header response on the collection. This PUT indicator doesn't mean you are going to use PUT on the collection itself, for me it means that the PUT can be used into the collection. Just the same when you have write access to a directory. It doesn't mean you will "write the directory", it means you'll "write _into_ the directory" instead. Many major servers do this for decades and I'd not call it an RFC violation, just the opposite. Furthermore, at least in case of the evolution-data-server CalDAV/CardDAV implementation, it's not going to issue PUT on the collection itself, I miss what it would do at the first place (because collection behaves just like a directory), it's always using PUT on a resource in that collection. The imagination of "collection=directory, resource=file" quite precisely matches how things work (it doesn't mean how the server stores them, only how it works) and with that on mind things make more sense. That's kind of supported by [2], at least as I understand it now.

[2] https://tools.ietf.org/html/rfc4918.html#section-5.2

> The asterisk sounded to me like a way to get what we want, like when being used > on this URL:
>   https://www.example.com/dav/me/calendar/*
> then I'd expect to get the same as I currently get with
>   https://www.example.com/dav/me/calendar/
> on all those servers I named at comment #2. Unfortunately, when I re-read the 4.3.7 section I'm less convinced it would be it. 

Yeah, based on that section I too don't think it'll work. The asterisk version seems permitted only without an absolute path and isn't defined for subresources.

> By the way, I do not understand your point here. I do not know what the problem > is to return also PUT in the OPTIONS Allow header response on the collection.
> This PUT indicator doesn't mean you are going to use PUT on the collection
> itself, for me it means that the PUT can be used into the collection. Just the
> same when you have write access to a directory. It doesn't mean you will "write
> the directory", it means you'll "write _into_ the directory" instead. Many
> major servers do this for decades and I'd not call it an RFC violation, just
> the opposite.

I think here lies our primary disagreement. You're saying the Allow header in response to OPTIONS /foo also apply to /foo/bar whereas I argue it doesn't. I think so for the following reasons:

- DAV is still HTTP underneath and its rules apply. https://tools.ietf.org/html/rfc7231#section-4.3.7 states "requests information about the communication options available for the target resource" --- target resource, not _and nested resources_. While related, a parent and a subresource can and do have entirely different supported methods.

- It'd be rather confusing if OPTIONS recursed like you're saying it does. Surely you're not assuming event resources support PROPFIND or REPORT just because the calendar resource advertises them in the allow header? If you don't, then we're down to subjective picking which of those advertised methods apply to to the parent, which to the immediate subresources and which to ones nested deeper.

- https://tools.ietf.org/html/rfc4918.html#section-5.2 doesn't change the meaning of the Allow header. I'd say it merely highlights that some of the methods on a collection resource don't return data about the collection as a whole. REPORT could be said to apply to only resources inside. PROPFIND can do both and hence 5.2's reference to the Depth header.

- That Fastmail (the Cyrus DAV server) doesn't support PUT on the collection should be another giveaway.

- The only justification of checking PUT on the collection came from an example in the CalDAV spec that wasn't highlighting anything about that method.

> Furthermore, at least in case of the evolution-data-server CalDAV/CardDAV
> implementation, it's not going to issue PUT on the collection itself, I miss
> what it would do at the first place (because collection behaves just like a directory)

Exactly. PUT isn't defined for collections in DAV. Weren't you suspicions of the Cyrus server (Fastmail's) not advertising it and the spec not mentioning anything about "Add PUT to the Allow header to indicate subresource mutability"?

I agree with Andri.  Using OPTIONS to check for write access on a collection is not the correct method.  Since CalDAV requires support for WebDAV ACL, checking the DAV:current-user-privilege-set property is the proper method of checking for write access.  Most (all?) servers don't support PUT on a collection, so responding to an OPTIONS request on a collection with Allow:PUT is nonsensical.

The Cyrus server responds to an OPTIONS request on a collection with Allow:POST because it supports RFC 5995.  So yes, this is an indication that the collection is writeable, but its still not the proper way to detect writability IMHO.

(In reply to Andri Möll from comment #9)
> You're saying the Allow header in response to OPTIONS /foo also apply
> to /foo/bar whereas I argue it doesn't.

Well, not in general, no. What I say is: if the collection has Allow PUT, then I can (safely?) expect the collection is writeable (just like directory is writeable), thus I can use PUT to add/modify resources in this collection (just like files in the directory). It's expected the respective resource in the collection can reject the PUT operation (again, just like with files in the directory).

> - It'd be rather confusing if OPTIONS recursed like you're saying it does.

Did I? I do not see it, I'm sorry.

> Surely you're not assuming event resources support PROPFIND or REPORT
> just because the calendar resource advertises them in the allow header?

Some operations are mandatory on collections, declared as such by the RFC. I'd not expect REPORT doing anything on a resource, while properties can be queried and changed on both resources and collections.

> If you don't, then we're down to subjective picking which of those
> advertised methods apply to to the parent, which to the immediate
> subresources and which to ones nested deeper.

Yes, and you said that, there's the Depth header for it in those operations which can be run on both collections and resources. OPTIONS doesn't seem to be one of them. That's true.

> - That Fastmail (the Cyrus DAV server) doesn't support PUT on the collection
> should be another giveaway.

The thing is that fastmail is the only server which does that for CalDAV, as far as I know. Do you think that everyone else would be doing it wrong for decades? I doubt it.

> - The only justification of checking PUT on the collection came from an
> example in the CalDAV spec that wasn't highlighting anything about that
> method.

To be honest, I do not think so. I'm not the original author of the CalDAV backend in eds, even I rewrote significant part of it. This checking for writeability is there from the beginning, as far as I know. What the reason was I do not know. It worked till Fastmail implementation (and now yours).

> PUT isn't defined for collections in DAV.

PUT operation is not defined, we already agreed on that. There's no doubt about it, but the server can claim in the OPTIONS response that PUT is the same as 'writeable' attribute on a directory.

> Weren't you suspicions of the Cyrus server (Fastmail's) not advertising it
> and the spec not mentioning anything about "Add PUT to the Allow header to
> indicate subresource mutability"?

No, it was the only server doing that and it was a new implementation. They can be wrong, comparing to all other servers out there. It's just one of many.

The main problem is that the RFCs are too vague with respect of OPTIONS and the Allow header of its response on collections and eventually resources. When you find something about OPTIONS, then it's a generic thing of HTTP, not WebDAV. I doubt any client issues OPTIONS on a resource first, before trying to do any operation on it. That will just make things slower, significantly. It's easier to let the server fail and return an error.

That's why I understood the PUT check in OPTIONS Allow header response on a collection as a shortcut to ACL query in eds. Okay, it can be also wrong.

(In reply to Ken Murchison from comment #10)
> Since CalDAV requires support for WebDAV ACL,
> checking the DAV:current-user-privilege-set property is the proper method of
> checking for write access. 

Right, though even that can be disabled on the server. I know the RFC 3744, specifically mentions that to be used to check collection's writeability, still the PUT in Allow of OPTIONS on the same collection seems like a good shortcut. Whether all the other servers understand it the same I cannot tell, it's not the question for me.

> Most (all?) servers don't support PUT on a collection, so responding to
> an OPTIONS request on a collection with Allow:PUT is nonsensical.

None should allow PUT on the collection, but they can do PUT into the collection.

> ...but its still not the proper way to detect writability IMHO.

You are right, the ACL is better and suggested method by the RFC authors, the eds code has just a shortcut which may (or may not) work just by an accident till now.

(In reply to Milan Crha from comment #11)
> (In reply to Andri Möll from comment #9)
> > You're saying the Allow header in response to OPTIONS /foo also apply
> > to /foo/bar whereas I argue it doesn't.
> 
> Well, not in general, no. What I say is: if the collection has Allow PUT,
> then I can (safely?) expect the collection is writeable (just like directory
> is writeable), thus I can use PUT to add/modify resources in this collection
> (just like files in the directory). It's expected the respective resource in
> the collection can reject the PUT operation (again, just like with files in
> the directory).
> 
> > - It'd be rather confusing if OPTIONS recursed like you're saying it does.
> 
> Did I? I do not see it, I'm sorry.

Recursion followed from your expectation that methods on a collection are an indication of methods allowed on its members AND/OR that some advertised methods on a collection really only apply to its children --- PUT being the one you're arguing for.  

> Some operations are mandatory on collections, declared as such by the RFC.
> I'd not expect REPORT doing anything on a resource, while properties can be
> queried and changed on both resources and collections.
> 
> > If you don't, then we're down to subjective picking which of those
> > advertised methods apply to to the parent, which to the immediate
> > subresources and which to ones nested deeper.
> 
> Yes, and you said that, there's the Depth header for it in those operations
> which can be run on both collections and resources. OPTIONS doesn't seem to
> be one of them. That's true.

Okay, then we're down to the belief that Allow:PUT means that you can PUT _children_ and not the collection? I.e Allow:PUT on /foo has always meant that PUT is allowed on /foo/bar and its only me and Cyrus IMAP that didn't get the memo? How did you come to that belief? I don't see that aligning with any spec. I've not seen that pattern in any books on REST either and they're usually the most pedantic writers on HTTP you can find.

Developers, I suspect, implicitly agree --- a lot of web frameworks in languages fill the OPTIONS' Allow header based on defined route handlers. None that I know follow your interpretation and fill parent's Allow header with the methods of their children. 

> > - That Fastmail (the Cyrus DAV server) doesn't support PUT on the collection
> > should be another giveaway.
> 
> The thing is that fastmail is the only server which does that for CalDAV, as
> far as I know. Do you think that everyone else would be doing it wrong for
> decades? I doubt it.

Doing what wrong? Nobody's forbidding servers from supporting PUT on collections. After all, a server can support DAV and plain old REST at the same time on same paths. It's the client side this time that's inducing something from coincidental behavior they mustn't do.

For why non-spec compliant behavior or weird hacks generally persist is probably due to most people not being as confrontational or pedantic as others, and settle for adding a hack on top of a hack to get home at 5pm. Another reason, perhaps more likely, is that it's the customers that suffer most when things break and if either side has even a whiff of empathy, they can't just not work around spec-violations. Problem is, most developers stop there and don't follow up and fix the root cause. 
 
> The main problem is that the RFCs are too vague with respect of OPTIONS and
> the Allow header of its response on collections and eventually resources.
> When you find something about OPTIONS, then it's a generic thing of HTTP,
> not WebDAV. I doubt any client issues OPTIONS on a resource first, before
> trying to do any operation on it. That will just make things slower,
> significantly. It's easier to let the server fail and return an error.
> 
> That's why I understood the PUT check in OPTIONS Allow header response on a
> collection as a shortcut to ACL query in eds. Okay, it can be also wrong.

My understanding, as said in a previous comment, is that DAV extends HTTP and doesn't conflict with its definitions. Redefining OPTIONS's Allow would be a such a conflict. None of us are able to produce any references to specs that state that some advertised methods (in "Allow") on some resources indicate permitted methods of _subresources_ either.

I feel I'm in a position of having to prove a negative, which, as you know, is difficult. What argument would convince you? I asked Ken from Fastmail/Cyrus to pitch in. Would you like other members of CalConnect to pitch in as well for an appeal to authority or maybe we could agree that the OPTIONS approach is too error prone to continue and replace it with <current-user-privilege-set>? Evolution already gets props of the calendar resource. We're just talking of adding one more.

The response to an OPTIONS request, and the Allow header field specifically, only applies to the target resource and has nothing to do with its children, per RFC 7231.

I already agreed with you, namely here:

---vvvvvv---

(In reply to Milan Crha from comment #11)
> > ...but its still not the proper way to detect writability IMHO.
> 
> You are right, the ACL is better and suggested method by the RFC authors,
> the eds code has just a shortcut which may (or may not) work just by an
> accident till now.

---^^^^^^----

I'm just getting sick of this argue, especially when I did agree with you already. I do not think saying anything about 5pm is fair (neither bringing more developers from one community would help anything, you might rather convince the major players that they do things incorrectly and they should fix their servers, or tell you why they work the way they work). And if you think it's the way to push anyone anywhere, then, well, I can just won't fix this and repeat myself "because it works for all but the Fastmail server and your new server", thus "because the past shows it works, regardless what the spec is or is not specific enough about", but again, I do not want to argue, I already did agree with you. Thus, please....

Ah, my bad, I thought we were still discussing the validity of the OPTIONS approach even if we all agreed in the beginning that ACLs were the right long term solution. Also, apologies if I seemed pushy or arrogant. That was not my intention.

Okay, thanks. I know I'm stubborn. I really do not know where that logic in the eds code came from, it's just there and it works, or better it worked till now. I'll keep this in my todo list and I'll update this bug when I know more. I vaguely recall the ACL didn't work with some of those servers I've been playing with, but it can be just a subpart of it or something, I do not recall many details. The "worse" I'll keep there both ways, if nothing else then for the backward compatibility.

Wohoo. Thank you! If I can somehow help debug other CalDAV servers, let me know. I'm working with CalDAV daily in the upcoming week(s) anyways. I'm also "moll" on irc.gnome.org.

I've been thinking of a shortcut of "OPTIONS contains PUT/POST/DELETE, just make it writeable", but then I realized that some servers can add these into the response for a read-only calendar, thus giving a false impression for the user, thus I made the check in the Allow header response only as a fallback, just in case the current-user-privilege-set would fail for whatever reason (it can happen when the user has the privilege to read its own privilege disabled on the server). Even this works fine for the servers I have an account on, I rather commit it only into the development version, just in case it would cause any regression.

Created commit 39c401ca4 in eds master (3.29.2+)

The majority view is that the content of the Allow: header does not depend on the currently authenticated user -- all clients get DELETE, even though the server knows at the time when it sends the headers, that the client is not allowed to call HTTP DELETE.  The reason is, that the in the RFC nothing is stated about authentication:

https://lists.w3.org/Archives/Public/ietf-http-wg/2018AprJun/0349.html
https://github.com/httpwg/http-core/issues/97

and cyrus sticks to this:

https://github.com/cyrusimap/cyrus-imapd/issues/2390

So it is not a matter of having PUT in Allow, but a question, whether the server returns the same answer to all - authenticated and unathenticated - requests.

Do DAViCal, Google, ownCloud, Yahoo!, Zimbra, iCloud, Radicale and Yandex honour the ACLs of the authenticated user, when generating Allow:?

Does it matter? Maybe if you carefully re-read comment #18... :(

WebDAV ACL / RFC 3744 defines DAV:write possibly as aggregate permission consisting of DAV:bind, DAV:unbind, DAV:write-properties and DAV:write-content.

On my system the CardDAV collection URL has the DAV:read (GET, HEAD, PROPFIND, REPORT), DAV:write-content (PUT, PATCH), DAV:unbind (DELETE, MOVE) and DAV:bind (POST) privileges. It is missing DAV:write so no DAV:write-properties (PROPPATCH).

DAVdroid considers a collection as writable if it has DAV:write, DAV:writte-content or DAV:all privileges (https://gitlab.com/bitfireAT/dav4android/blob/master/src/main/java/at/bitfire/dav4android/property/CurrentUserPrivilegeSet.kt#L43). 

This helps for address books in Evolution to be writable, when DAV:write-content without DAV:write is returned in DAV:current-user-privilege-set:

diff --git a/src/addressbook/backends/webdav/e-book-backend-webdav.c b/src/addressbook/backends/webdav/e-book-backend-webdav.c
--- a/src/addressbook/backends/webdav/e-book-backend-webdav.c
+++ b/src/addressbook/backends/webdav/e-book-backend-webdav.c
@@ -176,6 +176,7 @@ ebb_webdav_connect_sync (EBookMetaBackend *meta_backend,
 
                                if (privilege) {
                                        is_writable = privilege->hint == E_WEBDAV_PRIVILEGE_HINT_WRITE ||
+                                               privilege->hint == E_WEBDAV_PRIVILEGE_HINT_WRITE_CONTENT ||
                                                privilege->hint == E_WEBDAV_PRIVILEGE_HINT_ALL;
                                }
                        }

Okay, it makes sense. Two things:
a) if you want to propose patches, then do that with patch attachments. Text
   pasted in the comment is quite hard to apply, not talking that the browser
   can garble the content (white-spaces, wrapping and such)
b) I do not see the reason why to do this for CardDAV, but not for CalDAV. Is it
   because your server does it differently for the two? Anyway, I made it work
   the same for both.

Created commit 51f552df0 in eds master (3.29.4+)

This is valid for CalDAV too, but I have made only tests for CardDAV.

I assumed for one-line changes it makes no difference between a patch file and inline changes on the work to handle them.