Closed Bug 1941840 Opened 1 year ago Closed 1 year ago

TB Calendar synchronisation via DavMail to MS Exchange did only work for a newly in TB created calendar

Categories

(Calendar :: Provider: CalDAV, defect)

Thunderbird 128
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: Robert_Hartmann, Unassigned)

References

Details

Attachments

(1 file)

Steps to reproduce:

  1. create a new calendar and connect it via davmail to a personal calendar on an Exchange Server.
  2. see all calendar entries get shown in Thunderbird
  3. create a new calendar entry.

More about configuration steps for Thunderbird 128.5.2esr (64-Bit) are here:
https://github.com/mguessan/davmail/issues/375#issuecomment-2560403292

Actual results:

new calendar entry is only visible for some seconds in TB - but stay visible in OWA after creation in TB.

Name Thunderbird
Version 128.6.0esr
Build-ID 20250107005646
========Thunderbird Error Console========
16:09:25.997
PUT http://localhost:1080/users/email@domain.tld/calendar/6c203f24-42cb-479e-a26a-7e2d477c1f1a.ics[HTTP/1.1 201 Created 1312ms]

16:09:27.343
REPORT http://localhost:1080/users/email@domain.tld/calendar/[HTTP/1.1 207 Multi-Status 213ms]

16:09:27.642
PROPFIND http://localhost:1080/users/email@domain.tld/calendar/[HTTP/1.1 207 Multi-Status 196ms]

16:09:27.869
PROPFIND http://localhost:1080/users/email@domain.tld/calendar/[HTTP/1.1 207 Multi-Status 423ms]

16:09:28.444
REPORT http://localhost:1080/users/email@domain.tld/calendar/[HTTP/1.1 207 Multi-Status 901ms]

16:09:29.362 XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden Adresse: moz-nullprincipal:{cad20183-f27c-4969-b5b0-2335c8280fb1} Zeile Nr. 180, Spalte 29: {cad20183-f27c-4969-b5b0-2335c8280fb1}:180:29

Davmail-Log see https://github.com/mguessan/davmail/issues/375#issuecomment-2593420370

Expected results:

new calendar entry should stay visible in TB calendar after the synchronization process is finished.

Sounds like an empty xml response was received from DavMail?

Component: Untriaged → Provider: CalDAV
Product: Thunderbird → Calendar

The Davmail-Log ( https://github.com/mguessan/davmail/issues/375#issuecomment-2593420370 )
contains these VCALENDAR structures:
a) TB generated VCALENDAR structure, which was send to DavMail
b) The VCALENDAR structure, which had been created by DavMail based on TB's VCALENDAR structure (before sending to Exchange Server)
c) The VCALENDAR structure, which has been send to DavMail from Exchange Server as reply to the inserted entry
d) The VCALENDAR structure to which DavMail transfomed the above structure from (c) befor it had been send to Thunderbird

And some other VCALENDAR structures where covered in the log, which had been send from Exchange via Davmail to Thunderbird because these entries are missing in TB calendar, too. (And they stay missing in TB, sadly.)

Beside the VCALENDAR structures in the DavMail-Log there are multiple XML-Structures covered.
Sadly the TB Error Console did not print out the information where the "XML-Verarbeitungsfehler: Kein Wurzel-Element" (= "no root element") happens.

My "human parser" (brain 1.0) for VCALENDAR-structures and XML-structures did not find a syntactical the problem.
Perhaps I have something overseen?

Compairing the time information

TB error console entry

16:09:29.362 XML-Verarbeitungsfehler: Kein Wurzel-Element gefunden Adresse: moz-nullprincipal:{cad20183-f27c-4969-b5b0-2335c8280fb1} Zeile Nr. 180, Spalte 29: {cad20183-f27c-4969-b5b0-2335c8280fb1}:180:29

maps to the last lines in DavMail log

END:VCALENDAR
</C:calendar-data><D:getetag>2025-01-14T10:02:27Z</D:getetag></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>
2025-01-15 16:09:29,343 DEBUG [CaldavConnection-65209] davmail  - > 
2025-01-15 16:09:29,343 DEBUG [CaldavConnection-65209] davmail  - > 0
2025-01-15 16:09:29,343 DEBUG [CaldavConnection-65209] davmail  - > 
2025-01-15 16:11:24,455 INFO  [CaldavConnection-65209] davmail.connection  - DISCONNECT - 127.0.0.1:65209 

Do you mean, that there is the problem cause?

(In reply to Robert Hartmann from comment #3)

</C:calendar-data><D:getetag>2025-01-14T10:02:27Z</D:getetag></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat></D:response></D:multistatus>

I found an information on stackoverflow about a former TB/Lightning version:

Quote from year 2016 taken from https://stackoverflow.com/a/40503463 :

The Report Response has http status code 200, but as it is a multistatus response Thunderbird/Lightning expects status code 207

But even if the http status code does not match, why the entry which could be seen in TB just after creating it there disapears after some seconds?

Or does the XML-Parsing error mean, that something before the multistatus xml-tag is missing?

2025-01-15 16:09:29,343 DEBUG [CaldavConnection-65209] davmail.caldav.CaldavConnection  - > <?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:" [ .... removed other content of log .... ]

I had a look to https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/207
there an example is written as

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 1241

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">

I.e. does TB need the first three lines before getting the xml structure from davmail?

See Also: → 1714975

(In reply to Robert Hartmann from comment #5)

<D:multistatus xmlns:D="DAV:">

I.e. does TB need the first three lines before getting the xml structure from davmail?

No, but if that is (all) that got sent, notice there is no closing tag, so invalid xml.

Please add the full logs, as txt attachment.

Hello,
it still takes some time to view the complete log files with regard to GDPR or IT security-relevant entries and, if necessary, to anonymise or otherwise shorten them appropriately.
Here is a suitable excerpt as a graphic attached.

(In reply to Robert Hartmann from comment #8)

Created attachment 9462958 [details]
Zerro-Bytes_in_VCALENDAR_entries_Bug.png

Hello,
it still takes some time to view the complete log files with regard to GDPR or IT security-relevant entries and, if necessary, to anonymise or otherwise shorten them appropriately.
Here is a suitable excerpt as a graphic attached.

Why it is a graphic ?
Because I took a screenshot of WinMerge-Window, in which I had compaired the DavMail-Logfile with Thunderbird's Error-console,
to be able to find the right place where the crash happened.

That shows Thunderbird gets invalid xml from davmail. That seems like a bug in davmail. Please file it with them instead (with a sample ical data that reproduces it).

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: