Mailing List Archive

On Mon, 2010-06-07 at 17:01 +1000, Michael Cassaniti wrote:
> Hi All,
> I am getting the following messages in my Apache logs from an iPhone I
> have polling a calendar:
>
> Access log: 58.104.140.176 - <src princ> [07/Jun/2010:16:43:39 +1000]
> "REPORT /davical/caldav.php/<dest princ>/<collection> HTTP/1.1" 207 15557
>
> Error log: [Mon Jun 07 16:43:39 2010] [error] [client 58.104.140.176]
> client denied by server configuration: /var/www/localhost/htdocs/<dest
> princ>
>
> The Apache server has it's directory root at /var/www/localhost/htdocs,
> and DAViCal as a web application is at
> /var/www/localhost/htdocs/davical. What I believe is happening is there
> is an access directly to the root (i.e.: https://servername/principal)
> rather than the given URL
> (https://servername/davical/caldav.php/principal/collection). I am not
> sure if the direct access to the root URL is caused by DAViCal sending
> an incorrect URL back, or if the client is trying the wrong URL straight up.
>
> I have tried to access the same calendar from Thunderbird on a different
> IP with the same errors being shown. Any ideas?

Hi Michael,

All of the Apple clients attempt to hit /principals/users/<username>/
and will autoconfigure if successful. It's harmless.

If you rewrite that URL into DAViCal to be handled by caldav.php then it
can even work... :-)

In due course I expect this will likely be replaced by requests
against /.well-known/caldav in line with the well-known URL RFC, which
similarly won't be inside the DAViCal namespace if installed in a
subdirectory, but which is much more amenable to a redirect than Apple's
current method.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Courage is your greatest present need.
------------------------------------------------------------------------

-------------- 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/20100607/7348138a/attachment.pgp>
-------------- next part --------------

An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100610/9ff1f3df/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4024 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100610/9ff1f3df/attachment.bin>
-------------- next part --------------

On Thu, 2010-06-10 at 16:26 +1000, Michael Cassaniti wrote:
>
>
> On 06/07/10 21:05, Andrew McMillan wrote:
> > On Mon, 2010-06-07 at 17:01 +1000, Michael Cassaniti wrote:
> >
> > > Hi All,
> > > I am getting the following messages in my Apache logs from an iPhone I
> > > have polling a calendar:
> > >
> > > Access log: 58.104.140.176 - <src princ> [07/Jun/2010:16:43:39 +1000]
> > > "REPORT /davical/caldav.php/<dest princ>/<collection> HTTP/1.1" 207 15557
> > >
> > > Error log: [Mon Jun 07 16:43:39 2010] [error] [client 58.104.140.176]
> > > client denied by server configuration: /var/www/localhost/htdocs/<dest
> > > princ>
> > >
> > > The Apache server has it's directory root at /var/www/localhost/htdocs,
> > > and DAViCal as a web application is at
> > > /var/www/localhost/htdocs/davical. What I believe is happening is there
> > > is an access directly to the root (i.e.: https://servername/principal)
> > > rather than the given URL
> > > (https://servername/davical/caldav.php/principal/collection). I am not
> > > sure if the direct access to the root URL is caused by DAViCal sending
> > > an incorrect URL back, or if the client is trying the wrong URL straight up.
> > >
> > > I have tried to access the same calendar from Thunderbird on a different
> > > IP with the same errors being shown. Any ideas?
> > >
> > Hi Michael,
> >
> > All of the Apple clients attempt to hit /principals/users/<username>/
> > and will autoconfigure if successful. It's harmless.
> >
> > If you rewrite that URL into DAViCal to be handled by caldav.php then it
> > can even work... :-)
> >
> > In due course I expect this will likely be replaced by requests
> > against /.well-known/caldav in line with the well-known URL RFC, which
> > similarly won't be inside the DAViCal namespace if installed in a
> > subdirectory, but which is much more amenable to a redirect than Apple's
> > current method.
> >
> > Cheers,
> > Andrew.
> >
> >
> >
> Hi Andrew,
>
> Just to highlight it again,
> "I have tried to access the same calendar from Thunderbird on
> a different IP with the same errors being shown. Any ideas?"
>
> From my testing the same issue occurs for Thunderbird as well, so it
> is not limited to the iPhone. I have the same URL configured in both.
> If it helps the following information is available in the error
> console of Thunderbird:
> CalDAV: recv:
> <multistatus>
> <response>
> <href>/davical/caldav.php/casso/.in/</href>
> <propstat>
> <prop>
> <getcontenttype>httpd/unix-directory</getcontenttype>
> <resourcetype>
> <collection></collection>
> <C:schedule-inbox></C:schedule-inbox>
> </resourcetype>
> </prop>
> <status>HTTP/1.1 200 OK</status>
> </propstat>
> <propstat>
> <prop>
> <getetag></getetag>
> </prop>
> <status>HTTP/1.1 404 Not Found</status>
> </propstat>
> </response>
> </multistatus>
>
> I believe there is a failure to lookup the tag for the schedule inbox.
> This could be the reason a query is run against the server's root
> location from Thunderbird, but it still doesn't make much sense to me.

Hi Michael,

Yes, the DAV::getetag is not defined for collections, so a 404 is being
returned for this property as a part of the 207 response.

It is not unusual for DAV servers to leave getetag undefined for
collections. The reason for this is that the definition of getetag is
that it should contain the value of an 'ETag' for a GET on the specified
resource... and the GET method is undefined for collections.

Of course DAViCal *does* actually respond to a GET on (calendar)
collections by constructing a .ics analogue of the events in the
calendar collection, but doing that in response to a PROPFIND for the
getetag is resource intensive and (I believe) unnecessary. If you can
show me why it might be useful to respond with a getetag to a collection
I'm sure it can be done, but I believe DAViCal is behaving pretty much
the same as any other CalDAV server in doing it this way.

The *interesting* message you are seeing is 'client denied by server
configuration'. This message is coming from Apache without DAViCal
getting involved, and suggests that something is wrong in the Apache
configuration which is stopping DAViCal from responding correctly (or
probably even responding at all). Make sure you don't have an
open_basedir setting, which was erroneously recommended in a few setup
guides, historically. Or maybe it's something as simple as what is
outlined here: http://www.raditha.com/blog/archives/896.html

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will win success in whatever calling you adopt.
------------------------------------------------------------------------

-------------- 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/20100610/b4aedf60/attachment-0001.pgp>
-------------- next part --------------