451388 - DAV_NOT_DAV Error on Thunderbird 3.x

Status: RESOLVED WORKSFORME

(Calendar :: Provider: CalDAV, defect)

Description

[km]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2pre) Gecko/2008081823 Lightning/0.6a1 Shredder/3.0a2pre

On my recent trunk builds of Thunderbird 3.x with lightning, lightning fails to connect to my caldav server with

Error code: DAV_NOT_DAV. Description: The resource at https://(ommited)  is either not a DAV collection or not available

This works on builds a few weeks older.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Stefan Sitter [:ssitter]]

Please note the exact version (build id) of the Lightning nightly build that fails and the nightly build that works. Can you narrow down the regression range to two consecutive nightly builds?

Comment 2

[km]

These are my own builds from cvs. The builds with the problem go back at least to August 18. The last build I did that worked was July 12.

I've posted what "help/about" tells me. If there is any more version info I can extract, please tell me how to get it.

Comment 3

[Bruno Browning]

you could create and set to true two boolean prefs calendar.debug.log and calendar.debug.log.verbose to get some hopefully useful information to show in the error console

Comment 4

[km]

That got me extra output:



CalDAV: send: <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/">
  <D:prop>
    <D:resourcetype/>
    <CS:getctag/>
  </D:prop>
</D:propfind>
[calAlarmService] starting...
CalDAV: Status 207 on initial PROPFIND for calendar MathCS
CalDAV: Authentication scheme Basic
CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:">
 <response>
  <href>/cal/caldav.php/km/home/</href>
  <propstat>
   <prop>
    <resourcetype>
     <collection/>
     <calendar xmlns="urn:ietf:params:xml:ns:caldav"/>
    </resourcetype>
    <HTTP://CALENDARSERVER.ORG/NS/:GETCTAG/>
   </prop>
   <status>HTTP/1.1 200 OK</status>
  </propstat>
 </response>
</multistatus>

Comment 5

[Bruno Browning]

You need to upgrade to a current DAViCal. Looks like you are using an older one which delivers a totally whacked response to the getctag query we added last month. The current DAViCal does not understand getctag either, but it responds to the query with a properly-formatted XML doc, so Sunbird is able to note the lack of server-side ctag support and carry on; with older versions of DAViCal it can't.

Comment 6

[Bruno Browning]

Closing this bug since this works for me with current calendar and current DAViCal. Reporter, if you still have this problem with current software please do reopen.

->WORKSFORME