Unable to delete CalDav-Events when URL is redirect
-
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.
-
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
DELETEwould 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
DELETEa 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.
-
@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
DELETEwould 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
DELETEa 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.
-
@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,
DELETEshould 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.
-
@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/caldavAnd since using this URL I am not able to delete events.
-
@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)?
-
@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.
-
This bug should have been fixed with dav4android/c392dacf.
-
Thank you very much!