Unable to delete CalDav-Events when URL is redirect

[lookshe]

There is a bug in dav4android when processing DELETE request. GET, PUT and PROPFIND requests process a redirection, while DELETE request does not do this.

https://gitlab.com/bitfireAT/dav4android/blob/master/src/main/java/at/bitfire/dav4android/DavResource.java#L148 <-- processes the request
https://gitlab.com/bitfireAT/dav4android/blob/master/src/main/java/at/bitfire/dav4android/DavResource.java#L224 <-- only checks the status and not if there was an redirect.

This is especially a problem when using Owncloud or Nextcloud well-known redirects to keep the URLs consistent.

[rfc2822]

Thanks for your suggestion.

There is a bug in dav4android when processing DELETE request. GET, PUT and PROPFIND requests process a redirection, while DELETE request does not do this.

I have omitted this by intention, but of course there might be a case where it’s needed. However, DAVdroid receives its resource paths directly from the server, so there should be no resource URLs that redirect. Also, I wanted to avoid deleting the wrong resource (for instance, caused by an erroneous redirect) and I have never seen that an already existing resource has been renamed by the server so that a redirect on DELETE would be necessary.

Could you please tell us your use case where this is required?

This is especially a problem when using Owncloud or Nextcloud well-known redirects to keep the URLs consistent.

Why would DAVdroid DELETE a well-known URL? It only deletes contacts, events and tasks from the server when they have been deleted locally before. Service detection with well-known URLs is in no way involved to that.

[lookshe]

@rfc2822 said in Unable to delete CalDav-Events when URL is redirect:

Thanks for your suggestion.

There is a bug in dav4android when processing DELETE request. GET, PUT and PROPFIND requests process a redirection, while DELETE request does not do this.

I have omitted this by intention, but of course there might be a case where it’s needed. However, DAVdroid receives its resource paths directly from the server, so there should be no resource URLs that redirect. Also, I wanted to avoid deleting the wrong resource (for instance, caused by an erroneous redirect) and I have never seen that an already existing resource has been renamed by the server so that a redirect on DELETE would be necessary.

But modifying a wrong resource is really better?
In my eyes every request should be process a correct redirect or none.

Could you please tell us your use case where this is required?

This case happens when using “/.well-known/caldav/” as URL for davdroid. After upgrading my installation there were some old links which did not work, so I decided to switch to these URL to get a working solution also if the background URL changes. But since then I am unable to delete events.

This is especially a problem when using Owncloud or Nextcloud well-known redirects to keep the URLs consistent.

Why would DAVdroid DELETE a well-known URL? It only deletes contacts, events and tasks from the server when they have been deleted locally before. Service detection with well-known URLs is in no way involved to that.

If only service detection is used, this will work of course. But if the discovered URL changes, I need to reconfigure everything. So I decided to directly use this existing rewrite to avoid problems when sometimes the URLs from Owncloud or Nextcloud change.

[rfc2822]

@lookshe said in Unable to delete CalDav-Events when URL is redirect:

But modifying a wrong resource is really better?
In my eyes every request should be process a correct redirect or none.

There’s no reason to know that the resource is wrong in advance. But you’re right, if the server for instance redirects all resources to a new location, DELETE should be working, too.

This case happens when using “/.well-known/caldav/” as URL for davdroid. After upgrading my installation there were some old links which did not work, so I decided to switch to these URL to get a working solution also if the background URL changes. But since then I am unable to delete events.

I still don’t understand the connection between well-known URLs and DELETE. Do you mean that all your server URLs (including all CalDAV/CardDAV resources) have moved to a new location? In this case, I’d understand it, but then it’s not related to well-known URLs.

[lookshe]

@rfc2822 said in Unable to delete CalDav-Events when URL is redirect:

I still don’t understand the connection between well-known URLs and DELETE. Do you mean that all your server URLs (including all CalDAV/CardDAV resources) have moved to a new location? In this case, I’d understand it, but then it’s not related to well-known URLs.

Of course this is not directly connected to the well-known URLs, I only use these ones to avoid problems when changing the location of CalDAV/CardDAV resources, like it happened while upgrading a owncloud/nextcloud installation. As I discovered the change in Owncloud and Nextcloud between 8.2 and 9.0 (https://github.com/owncloud/core/compare/v8.2.10...v9.0.8#diff-8052c42ab3b8aa06a3f5f788a4ddccc2R55 and https://github.com/nextcloud/server/compare/v8.2.7...v9.0.56#diff-8052c42ab3b8aa06a3f5f788a4ddccc2R55)

The old URL was something like this: https://domain.tld/remote.php/caldav/
The new one looks like this: https://domain.tld/remote.php/dav/

But to be sure this will not happen again, I decided to use the well-known URL, because this is an rewrite to the correct location, also if this location changes.
So now the URL, which I use, looks like this: https://domain.tld/.well-known/caldav

And since using this URL I am not able to delete events.

[rfc2822]

@lookshe I see. So the specific calendar resources (not the others like the ones used for principal detection) were also located at /remote.php/caldav/ and are now located at /remote.php/dav/ (with active redirects)?

[lookshe]

@rfc2822 said in Unable to delete CalDav-Events when URL is redirect:

@lookshe I see. So the specific calendar resources (not the others like the ones used for principal detection) were also located at /remote.php/caldav/ and are now located at /remote.php/dav/ (with active redirects)?

Yes, that is correct.

[rfc2822]

This bug should have been fixed with dav4android/c392dacf.

[lookshe]

Thank you very much!