Bug 1129002 - problem discovering calendars with radicale in non-root of Apache (fixed upstream)
Summary: problem discovering calendars with radicale in non-root of Apache (fixed upst...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: radicale
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Juan Orti Alcaine
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-12 04:21 UTC by John Heidemann
Modified: 2014-08-27 01:35 UTC (History)
2 users (show)

Fixed In Version: radicale-0.9-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-27 01:35:43 UTC


Attachments (Terms of Use)

Description John Heidemann 2014-08-12 04:21:14 UTC
Description of problem:
radicale's listing multiple calendars under a single user doesn't work
when radicale runs using apache for configuration,
IF radicale is not at the root of a virtual server.
(e.g., if it is at www.example.com/caldav/ instead of
caldav.example.com/).

Version-Release number of selected component (if applicable):
radicale-0.8-10.fc20.noarch


How reproducible:
every time

Steps to Reproduce:
1. set up radicale under a sub direcotry
2.giving www.example.com/caldav/user/
to acal (on android) checks out as caldav,
but it doesn't list any sub-calendars,
even if
www.example.com/caldav/user/foo.ics/
and
www.example.com/caldav/user/bar.ics/
exist.


Actual results:
see above

Expected results:
In acal, "list calendars" should find foo.ics and bar.ics.


Additional info:
why? apache strips off the /caldav/ base prefix.
Radicale then returns entries with short href's
(/user/, /user/foo.ics/, /user/bar.ics/)
in response to the PROPFIND Depth: 1 query during discovery.

But these hrefs are wrong... they're missing /caldav/.

One might think fixing this by putting 
base_prefix=/caldav/
in /etc/radicale/config 
would do the trick, but no:
because Apache strips that off, this config fails
the check "Path not starting with prefix"
in radicale.init.

Suggested fix:

add a new config parameter:
can_skip_base_prefix
that avoids this check. It all then works, provided this goes in the
config:
base_prefix=/caldav/
can_skip_base_prefix=True

Patch:

--- __init__.py-    2013-07-12 08:45:26.000000000 -0700
+++ __init__.py 2014-04-19 11:10:43.791856360 -0700
@@ -252,6 +252,8 @@
             environ["PATH_INFO"] = self.sanitize_uri(
                 "/%s" % environ["PATH_INFO"][len(base_prefix):])
             log.LOGGER.debug("Sanitized path: %s", environ["PATH_INFO"])
+        elif config.get("server", "can_skip_base_prefix"):
+            log.LOGGER.debug("skipped already sanitized path: %s", environ["PATH_INFO"])
         else:
             # Request path not starting with base_prefix, not allowed
             log.LOGGER.debug(
--- config.py-  2014-04-19 11:01:38.655498852 -0700
+++ config.py   2014-04-19 11:06:04.930683289 -0700
@@ -47,6 +47,7 @@
         "key": "/etc/apache2/ssl/server.key",
         "dns_lookup": "True",
         "base_prefix": "/",
+        "can_skip_base_prefix": "False",
         "realm": "Radicale - Password Required"},
     "encoding": {
         "request": "utf-8",

Th
is fix addresses two issues on
http://radicale.org/user_documentation/#idapache-and-mod-wsgi

the statement: "The [server] part of the configuration is ignored."
is not true. Giving a base_prefix is enforced.

The statement "You should use the root of the (sub)domain
(WSGIScriptAlias /), else some CalDAV features may not work." is true
and is the limitation I hit.
With the patch, this statement should change to :
"If you have a non-empty base_prefix, then you MUST set
"can_skip_base_prefix=True" in your config or some CalDAV features
(like discovering calendars) will not work.

This patch was accepted upstream, see https://github.com/Kozea/Radicale/issues/147

However, the update radicale-0.8-10.fc20.noarch broke my copy patched by hand.
It's unclear when upstream will do a release, so if the maintainer is interested,
they may wish to apply this patch to fedora as well until the 0.9 release.

Thanks.

Comment 1 Fedora Update System 2014-08-14 10:12:49 UTC
radicale-0.9-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/radicale-0.9-1.fc20

Comment 2 John Heidemann 2014-08-14 16:58:05 UTC
thanks, looks fixed to me with radicale-0.9-1.fc20

Comment 3 Fedora Update System 2014-08-16 00:32:40 UTC
Package radicale-0.9-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing radicale-0.9-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-9470/radicale-0.9-1.fc20
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2014-08-27 01:35:43 UTC
radicale-0.9-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.