Mailing List Archive

Unexpected status 200 while querying principal names
Hi Ruud,

On Mon, 05 Oct 2009 21:48:34 +0200
Ruud van der Velden <ruudvdvelden at chello.nl> wrote:

> [Sun Oct 04 21:37:38 2009] [error] [client 127.0.0.1] davical: LOG:
> headers:-->Content-type: text/html
This seems to be the error. Content-type should be text/calendar. Is
your apache server configured to always set content-type to text/html?

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Forrest Gump: "I'm sorry for ruining your party, Lieutenant
Dan. She tasted of cigarettes"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091005/140ce4d5/attachment-0001.pgp>
-------------- next part --------------
Unexpected status 200 while querying principal names [ In reply to ]
On 05/10/09 12:48, Ruud van der Velden wrote:
> Hello,
>
> I'm new to Caldav, PostgreSQL.
>
> I'm trying to setup Davical 0.9.7.2 on Windows. It took me a long time
> to get it up and running because of the many configurations that had to
> be done under Windows.
>
> I use it with Xampp (portable).
>
> My client is Mozilla Thunderbird (Windows) with Lighting add-on.
>
> When I try to reload the remote calendar I get some information messages
> in the Thunderbird error console:
>
> ---
> CalDAV: Unexpected status 200 while querying principal namespace
> ---
>
>
When you configured Thunderbird did you supply it with the full calendar
URL, or with the principal URL?

You should be using the full calendar URL, like:

http://davical.example.net/caldav.php/username/calendar/

I can see a bug where that response might be returned if the request
were made against a principal, and will fix that before I push out 0.9.7.3

Regards,
Andrew McMillan.
Unexpected status 200 while querying principal names [ In reply to ]
On Mon, 05 Oct 2009 15:21:53 -0700
Andrew McMillan <andrew at mcmillan.net.nz> wrote:

> When you configured Thunderbird did you supply it with the full calendar
> URL, or with the principal URL?
>
> You should be using the full calendar URL, like:
>
> http://davical.example.net/caldav.php/username/calendar/
>
> I can see a bug where that response might be returned if the request
> were made against a principal, and will fix that before I push out 0.9.7.3
>
When I do a request against the principal, which is perfectly valid, I
receive this response:

BEGIN:VCALENDAR
PRODID:-//davical.org//NONSGML AWL Calendar//EN
VERSION:2.0
CALSCALE:GREGORIAN
X-WR-CALNAME:Michael Rasmussen
END:VCALENDAR

This is a valid response so it might be a bug in Mozilla Lighting?

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Forrest Gump: "I'm sorry for ruining your party, Lieutenant
Dan. She tasted of cigarettes"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091006/c9021be8/attachment-0001.pgp>
-------------- next part --------------
Unexpected status 200 while querying principal names [ In reply to ]
On 05/10/09 13:02, Michael Rasmussen wrote:
> Hi Ruud,
>
> On Mon, 05 Oct 2009 21:48:34 +0200
> Ruud van der Velden<ruudvdvelden at chello.nl> wrote:
>
>
>> [Sun Oct 04 21:37:38 2009] [error] [client 127.0.0.1] davical: LOG:
>> headers:-->Content-type: text/html
>>
> This seems to be the error. Content-type should be text/calendar. Is
> your apache server configured to always set content-type to text/html?
>
That's certainly odd, too, and I suspect it might be an error due to
excessive debugging output causing the error.

I think people have to be very careful enabling debugging. In
particular setting:
$c->dbg['all'] = 1; // Don't do this unless you know what you're doing
can break the server in some cases where a debug log message accesses an
uninitialised variable, and PHP is set to E_ALL.

In such cases the response logging will not be correct, because it has
no knowledge of the earlier error message which caused the headers to be
sent early, etc. Similar issues exist for the case where output starts
early due to characters after a closing tag in the config file.

Perhaps one day I'll catch all of those warnings that happen in debug
messages, but I rarely enable 'all' debug myself, so the odds of me
catching them aren't generally very high.

But in any case, dbg['all'] provides waaaaaaayyy too much information to
be useful for solving setup problems. I generally find
dbg['querystring'] is the most useful starting point, although there are
some specific ones also for debugging authentication issues which can be
useful.

Cheers,
Andrew.
Unexpected status 200 while querying principal names [ In reply to ]
On 05/10/09 16:15, Michael Rasmussen wrote:
> On Mon, 05 Oct 2009 15:21:53 -0700
> Andrew McMillan<andrew at mcmillan.net.nz> wrote:
>
>
>> When you configured Thunderbird did you supply it with the full calendar
>> URL, or with the principal URL?
>>
>> You should be using the full calendar URL, like:
>>
>> http://davical.example.net/caldav.php/username/calendar/
>>
>> I can see a bug where that response might be returned if the request
>> were made against a principal, and will fix that before I push out 0.9.7.3
>>
>>
> When I do a request against the principal, which is perfectly valid, I
> receive this response:
>
> BEGIN:VCALENDAR
> PRODID:-//davical.org//NONSGML AWL Calendar//EN
> VERSION:2.0
> CALSCALE:GREGORIAN
> X-WR-CALNAME:Michael Rasmussen
> END:VCALENDAR
>
> This is a valid response so it might be a bug in Mozilla Lighting?
>

Funnily enough I just changed that behaviour :-)

I noticed that response to a GET on a principal URL this morning at
CalConnect and since I don't think a GET request against a non-calendar
collection should return a text/calendar :-)

The earlier request wasn't a GET, though, it was a PROPFIND which is
reasonable to see against a should return an XML document, so you were
correct that text/html was the wrong content type to see. Since the
server explicitly sets the header to text/xml the only reason I can
think of that it would be text/html would be because a PHP error message
started the output early...

... hence my second response, after I read your e-mail pointing out the
content-type anomaly :-)

Cheers,
Andrew.
Unexpected status 200 while querying principal names [ In reply to ]
Hello Andrew,Michael,

Thanks for your hints.

Fortunately I'm now able to connect and get/put some data from/to the
calendar.
I turned off the debug 'all' option AND setup the proper url for the
calendar (http://localhost/caldav.php/<username>/home/ in my case).

Now that I have a kind of working configuration I'm motivated again to
look deeper into this product :-)

In the end I need to have a very small solution for a private network
with one (maybe two) calendar which can be viewed and maintained by
multiple (1-3) users at the 'same' time. My guess is that Davical is
capable of doing so because of the underlaying database?

In the current situation (NOT calidav) I use a webdav server which
stores an iCal file. This sometimes gives problems when two people edit
simultanously. Furthermore the iCal file keeps growing, forcing the
client to download it, read the whole file etc. making it slow
performing after some time.

When I really implement Davical I will consider writing a manual for
Windows users, using Xampp. (I suppose uploading a .docx file is no
problem ;-)

Thanks again,
Ruud


Andrew McMillan wrote:
> On 05/10/09 13:02, Michael Rasmussen wrote:
>> Hi Ruud,
>>
>> On Mon, 05 Oct 2009 21:48:34 +0200
>> Ruud van der Velden<ruudvdvelden at chello.nl> wrote:
>>
>>
>>> [Sun Oct 04 21:37:38 2009] [error] [client 127.0.0.1] davical: LOG:
>>> headers:-->Content-type: text/html
>>>
>> This seems to be the error. Content-type should be text/calendar. Is
>> your apache server configured to always set content-type to text/html?
>>
> That's certainly odd, too, and I suspect it might be an error due to
> excessive debugging output causing the error.
>
> I think people have to be very careful enabling debugging. In
> particular setting:
> $c->dbg['all'] = 1; // Don't do this unless you know what you're doing
> can break the server in some cases where a debug log message accesses an
> uninitialised variable, and PHP is set to E_ALL.
>
> In such cases the response logging will not be correct, because it has
> no knowledge of the earlier error message which caused the headers to be
> sent early, etc. Similar issues exist for the case where output starts
> early due to characters after a closing tag in the config file.
>
> Perhaps one day I'll catch all of those warnings that happen in debug
> messages, but I rarely enable 'all' debug myself, so the odds of me
> catching them aren't generally very high.
>
> But in any case, dbg['all'] provides waaaaaaayyy too much information to
> be useful for solving setup problems. I generally find
> dbg['querystring'] is the most useful starting point, although there are
> some specific ones also for debugging authentication issues which can be
> useful.
>
> Cheers,
> Andrew.
>
>
Unexpected status 200 while querying principal names [ In reply to ]
Hi Ruud,

On Tue, 06 Oct 2009 21:33:02 +0200
Ruud van der Velden <ruudvdvelden at chello.nl> wrote:

A small piece of advice:-)

> I turned off the debug 'all' option AND setup the proper url for the
> calendar (http://localhost/caldav.php/<username>/home/ in my case).
>
To get rid off having caldav.php as part of the URL ad this to your
virtual host configuration - somewhere inside
<VirtualHost>
.....

RewriteEngine On

# Not if it explicitly specifies a .php program, stylesheet or
# image
RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)

# Everything else gets rewritten to /caldav.php/...
RewriteRule ^(.*)$ /caldav.php$1 [NC,L]

</VirtualHost>

The above means you can use URL's like this:
http://localhost/<username>/home/

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Forrest Gump: "I'm sorry for ruining your party, Lieutenant
Dan. She tasted of cigarettes"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091006/35f707f0/attachment.pgp>
-------------- next part --------------
Unexpected status 200 while querying principal names [ In reply to ]
On 06/10/09 12:33, Ruud van der Velden wrote:
> Hello Andrew,Michael,
>
> Thanks for your hints.
>
> Fortunately I'm now able to connect and get/put some data from/to the
> calendar.
> I turned off the debug 'all' option AND setup the proper url for the
> calendar (http://localhost/caldav.php/<username>/home/ in my case).
>
> Now that I have a kind of working configuration I'm motivated again to
> look deeper into this product :-)
>
> In the end I need to have a very small solution for a private network
> with one (maybe two) calendar which can be viewed and maintained by
> multiple (1-3) users at the 'same' time. My guess is that Davical is
> capable of doing so because of the underlaying database?
>
Well, CalDAV doesn't depend on having an underlying database, but I
chose to implement with a database because it makes some things
simpler. Using PostgreSQL, in particular, makes date handling very easy
also.


> In the current situation (NOT calidav) I use a webdav server which
> stores an iCal file. This sometimes gives problems when two people edit
> simultanously. Furthermore the iCal file keeps growing, forcing the
> client to download it, read the whole file etc. making it slow
> performing after some time.
>
Yes, this is typically the major problem with WebDAV. Of course
calendars can keep growing with CalDAV too, but it's theoretically
possible for the client to take some kinds of actions to lessen the
bandwidth impact.

Some clients still don't behave so well with large calendars, though,
and in particular this can be a problem on initial load.

> When I really implement Davical I will consider writing a manual for
> Windows users, using Xampp. (I suppose uploading a .docx file is no
> problem ;-)
>
I'm happy to accept documentation in whatever format people choose to
write it, though I would tend to convert it to OpenDocument if it's
going to be included within the DAViCal distribution.

Cheers,
Andrew.