Mailing List Archive: DAViCal: General

Moving events between calendars in iCal

Index | Next | Previous | View Threaded

davical at aiic

Jul 29, 2011, 10:02 AM

Post #1 of 4 (424 views)
Permalink

Moving events between calendars in iCal

I have davical 0.9.9.4-1 running on a debian. Using it with iCal 5.0
(Lion), I cannot switch events from one calendar to another one. Both,
the src and the dst calendar are owned by me.

In the apache access log:
MOVE /caldav.php/USER/home/XXXXXXX.ics HTTP/1.0" 409 37 "-"
"CalendarStore/5.0 (1127); iCal/5.0 (1535); Mac OS X/10.7 (11A511)"

In the apache error log:
davical: LOG: response:-->Destination collection does not exist

What's going wrong here? Switching an event with an iOS client does work.

------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

andrew at morphoss

Sep 9, 2011, 7:24 PM

Post #2 of 4 (306 views)
Permalink

Re: Moving events between calendars in iCal [In reply to]

On Fri, 2011-09-09 at 23:06 +0200, Martin wrote:
> Hi all
>
> iCal5 still has the problem with the MOVE of an event to another
> calendar. Trying to move an event from my home calendar to the work
> one, the debug log shows the following:
>
> davical: LOG: :***************** Request Header ****************
> davical: LOG: :MOVE /caldav.php/USER/home/xxxxxx-3A8CE09202AA.ics
> ...
> davical: LOG: headers:-->Destination:
> https://HOSTNAME:8443/caldav.php/USER/work/xxxxxx-3A8CE09202AA.ics
> ...
> davical: LOG: :******************** Request ********************
>
> The destination contains the full URL including protocol, hostname,
> port and base. In DAVResource, this destination string is matched
> against the collections in the DB then. However, they all start with
> /USER and do not contain the host parts.

Interesting. I wasn't aware of this problem, so thanks for the
notification. I'll ask about it if I manage to talk to the iCal
developers, because I'm pretty sure from other discussions with Cyrus
Daboo that cross-host MOVE is neither recommended nor supported, and
consequently it is kind of silly to provide protocol/host/port
information with it.

Cheers,
Andrew.

> Stripping an existing host from the destination string fixes the
> problem. The following is a dirty dirty hack/patch:
>
>
>
> --- caldav-MOVE.php.orig 2011-09-09 21:47:06.000000000 +0200
> +++ caldav-MOVE.php 2011-09-09 22:45:00.000000000 +0200
> @@ -24,6 +24,7 @@
>
> $lock_opener = $request->FailIfLocked();
>
> +$request->destination =
> str_replace('https://HOSTNAME:8443/caldav.php','',
> $request->destination);
> $dest = new DAVResource($request->destination);
>
> if ( $dest->dav_name() == '/' || $dest->IsPrincipal() ) {
>
>
>
> cheers
> Martin
>
>
>
> On 2011-07-29 17:02, Martin wrote:
> > I have davical 0.9.9.4-1 running on a debian. Using it with iCal 5.0
> > (Lion), I cannot switch events from one calendar to another one.
> > Both, the src and the dst calendar are owned by me.
>
> > In the apache access log:
> > MOVE /caldav.php/USER/home/XXXXXXX.ics HTTP/1.0" 409 37 "-"
> > "CalendarStore/5.0 (1127); iCal/5.0 (1535); Mac OS X/10.7 (11A511)"
>
> > In the apache error log:
> > davical: LOG: response:-->Destination collection does not exist
>
> > What's going wrong here? Switching an event with an iOS client does work.
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Davical-general mailing list
> Davical-general [at] lists
> https://lists.sourceforge.net/lists/listinfo/davical-general
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Gravity:
What you get when you eat too much and too fast.
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

andrew at morphoss

Sep 11, 2011, 4:49 AM

Post #3 of 4 (298 views)
Permalink

Re: Moving events between calendars in iCal [In reply to]

On Sat, 2011-09-10 at 11:10 +0200, Martin wrote:
> Hi Andrew
>
> Quoting Andrew McMillan <andrew [at] morphoss>, Sat, 10 Sep 2011
> 14:24:13 +1200:
>
> > because I'm pretty sure from other discussions with Cyrus
> > Daboo that cross-host MOVE is neither recommended nor supported, and
> > consequently it is kind of silly to provide protocol/host/port
> > information with it.
>
> digging around in the CalDAV/WebDAV RFCs, I found the section below
> covering destination URIs. Based on that, iCal5 seems to be conform
> ("it _may_ name a different server").
>
> Even if the destination URI is an absolute one, DAViCal could check if
> the destination URI points to the same server instance and only fail
> to execute the COPY/MOVE, if it is actually a remote URI.

Yep, it's allowed according to DAV. Equally it's OK for the server to
refuse it :-)

Checking the protocol/host/port is the same is a more complex problem
than you think, due to problems with multiple DNS names and default
ports.

I've committed a patch that just strips the hostname out. If it fails
after that it's because a person didn't have the rights to write to that
location on *this* server, and that's fine.

http://repo.or.cz/w/davical.git/commit/6f8e2b1d6e591c5da87591b4b0c7191a7b8e09a1

And it's included in 0.9.9.5 :-)

Cheers,
Andrew.

>
> cheers
> Martin
>
> =================
>
> http://tools.ietf.org/html/rfc4918.html#section-10.3
>
> 10.3 Destination Header
>
> The Destination request header specifies the URI that identifies a
> destination resource for methods such as COPY and MOVE, which take
> two URIs as parameters.
>
> Destination = "Destination" ":" Simple-ref
>
>
> If the Destination value is an absolute-URI (Section 4.3 of
> [RFC3986]), it may name a different server (or different port or
> scheme). If the source server cannot attempt a copy to the remote
> server, it MUST fail the request. Note that copying and moving
> resources to remote servers is not fully defined in this
> specification (e.g., specific error conditions).
>
> If the Destination value is too long or otherwise unacceptable, the
> server SHOULD return 400 (Bad Request), ideally with helpful
> information in an error body.
>
> ------------------------------------------------------------------------------
> Malware Security Report: Protecting Your Business, Customers, and the
> Bottom Line. Protect your business and customers by understanding the
> threat from malware and how it can impact your online business.
> http://www.accelacomm.com/jaw/sfnl/114/51427462/
> _______________________________________________
> Davical-general mailing list
> Davical-general [at] lists
> https://lists.sourceforge.net/lists/listinfo/davical-general
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Why be a man when you can be a success?
-- Bertolt Brecht
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

davical at aiic

Sep 11, 2011, 8:51 AM

Post #4 of 4 (289 views)
Permalink

Re: Moving events between calendars in iCal [In reply to]

Quoting Andrew McMillan <andrew [at] morphoss>, Sun, 11 Sep 2011
23:49:38 +1200:

> I've committed a patch that just strips the hostname out. If it fails
> after that it's because a person didn't have the rights to write to that
> location on *this* server, and that's fine.

works for me, thanks!

------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads