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.


  • developer

    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.



  • @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.


  • developer

    @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.



  • @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.


  • developer

    @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.


  • developer

    This bug should have been fixed with dav4android/c392dacf.



  • Thank you very much!


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.