On Wed, 2010-04-14 at 10:53 +0200, Robert Priewasser wrote:
> Hi,
> I installed DAViCal on my Ubuntu Hardy Server, version 0.9.8.4, db: 1.2.7
> I can access the configuration webpage of davical, also the Administration ->
> Setup page shows no errors.
> At my client (kontact) I could successfully read the calendar file, but as
> soon as I want to upload a calendar entry (after giving my user/pwd) I get an
> access denied while attempting to upload it.
>
> My apache config, under a VirtualHost section looks like this:
>
> <Directory /var/www/davical/>
> AllowOverride none
> Order allow,deny
> Allow from all
> php_value include_path /usr/share/awl/inc
> php_value magic_quotes_gpc 0
> php_value register_globals 0
> php_value open_basedir 1
> php_value error_reporting "E_ALL & ~E_NOTICE"
> php_value default_charset "utf-8"
> </Directory>
>
> /var/www/davical/ is a symlink to the installation
> dir /usr/share/davical/htdocs
>
> The apache access log shows the following error:
>
> x.x.x.x - robert [14/Apr/2010:10:44:23
> +0200] "GET /davical/caldav.php/robert/home/ HTTP/1.1" 200
> 143 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like
> Gecko) (Kubuntu)"
> x.x.x.x - robert [14/Apr/2010:10:44:26
> +0200] "PUT /davical/caldav.php/robert/home/ HTTP/1.1" 405 - "-" "Mozilla/5.0
> (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Kubuntu)"
>
> I get the same for http and https.
Hi Robert,
Firstly, delete the open_basedir line from your Apache virtual host to
avoid future pain :-)
The problem that you describe here, however, is that kontact is not a
CalDAV client. It is simply using HTTP PUT to replace the entire
calendar, rather than replacing one event at a time.
That mode of operation is not recommended, since it doesn't scale, and
chews bandwidth, server CPU, doesn't provide great comfort for if two
people are trying to edit the same calendar, etc, etc,. All problems
that CalDAV is designed to avoid, by only editing single events, and
providing modification check mechanisms and so forth.
However, all those caveats aside, DAViCal *does* support rewriting the
whole calendar in this way, for compatibility with legacy clients such
as yours. You need to check out this setting here:
http://wiki.davical.org/w/Configuration/settings/readonly_webdav_collections
There is also now a kcaldav plugin, which I believe might allow you to
use CalDAV protocol, although getting a version which worked on Ubuntu
Hardy might be a job for superman :-)
Regards,
Andrew.
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Don't engineer in a crisis. -- Vint Cerf speaking on IPv6
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100414/39ef53fb/attachment-0001.pgp>
-------------- next part --------------
> Hi,
> I installed DAViCal on my Ubuntu Hardy Server, version 0.9.8.4, db: 1.2.7
> I can access the configuration webpage of davical, also the Administration ->
> Setup page shows no errors.
> At my client (kontact) I could successfully read the calendar file, but as
> soon as I want to upload a calendar entry (after giving my user/pwd) I get an
> access denied while attempting to upload it.
>
> My apache config, under a VirtualHost section looks like this:
>
> <Directory /var/www/davical/>
> AllowOverride none
> Order allow,deny
> Allow from all
> php_value include_path /usr/share/awl/inc
> php_value magic_quotes_gpc 0
> php_value register_globals 0
> php_value open_basedir 1
> php_value error_reporting "E_ALL & ~E_NOTICE"
> php_value default_charset "utf-8"
> </Directory>
>
> /var/www/davical/ is a symlink to the installation
> dir /usr/share/davical/htdocs
>
> The apache access log shows the following error:
>
> x.x.x.x - robert [14/Apr/2010:10:44:23
> +0200] "GET /davical/caldav.php/robert/home/ HTTP/1.1" 200
> 143 "-" "Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like
> Gecko) (Kubuntu)"
> x.x.x.x - robert [14/Apr/2010:10:44:26
> +0200] "PUT /davical/caldav.php/robert/home/ HTTP/1.1" 405 - "-" "Mozilla/5.0
> (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Kubuntu)"
>
> I get the same for http and https.
Hi Robert,
Firstly, delete the open_basedir line from your Apache virtual host to
avoid future pain :-)
The problem that you describe here, however, is that kontact is not a
CalDAV client. It is simply using HTTP PUT to replace the entire
calendar, rather than replacing one event at a time.
That mode of operation is not recommended, since it doesn't scale, and
chews bandwidth, server CPU, doesn't provide great comfort for if two
people are trying to edit the same calendar, etc, etc,. All problems
that CalDAV is designed to avoid, by only editing single events, and
providing modification check mechanisms and so forth.
However, all those caveats aside, DAViCal *does* support rewriting the
whole calendar in this way, for compatibility with legacy clients such
as yours. You need to check out this setting here:
http://wiki.davical.org/w/Configuration/settings/readonly_webdav_collections
There is also now a kcaldav plugin, which I believe might allow you to
use CalDAV protocol, although getting a version which worked on Ubuntu
Hardy might be a job for superman :-)
Regards,
Andrew.
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Don't engineer in a crisis. -- Vint Cerf speaking on IPv6
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100414/39ef53fb/attachment-0001.pgp>
-------------- next part --------------