582089 - caldav won't display calendar items if they are marked with a content type of "text/plain"

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Nathaniel Madura]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.15) Gecko/2009102617 Camino/2.0 (like Firefox/3.0.15)
Build Identifier: From comm-1.9.2

We run an Apple Calendar server, and for whatever reason, many of our calendar events are marked as "text/plain" instead of "text/calendar"

I assume this has something to do with an older client of iCal somewhere, as current versions of iCal seem to be setting the content-type correctly. Never-the-less we have thousands of entries that are set incorrectly. 

It is my assumption, that if I am seeing this problem, others may see this problem as well. 

Reproducible: Always




I have a fix, below is the unified diff

--- calendar-js/calDavRequestHandlers.js	2010-07-26 17:35:44.000000000 -0400
+++ /Users/Shared/comm-1.9.2/calendar/providers/caldav/calDavRequestHandlers.js	2010-07-21 15:54:00.000000000 -0400
@@ -277,11 +277,6 @@
                         // contenttype to be returned.
                         r.getcontenttype = "text/calendar";
                     }
-						  if (r.getcontenttype.substr(0, 10) == "text/plain") {
-							  // workaround a bug -- that has been fixed -- in 
-							  // Apple's implementation
-							  r.getcontenttype = "text/calendar";
-						  }
                     if (r.getcontenttype == "text/vtodo") {
                         // workaround Kerio wierdness
                         r.getcontenttype = "text/calendar";

Comment 1

[Nathaniel Madura]

After further research, I think that it is inappropriate to rely on the getcontenttype property altogether. Per the DAV spec, there is no requirement that the content-type be set correctly. More to the point, who is to say a content-type of text/plain or message/rfc822 or other is actually incorrect?

Patch to follow

Comment 2

[Nathaniel Madura]

Attachment: removes all usage of the getcontenttype tag to filter out calendar events

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 460550 [details] [diff] [review]
removes all usage of the getcontenttype tag to filter out calendar events

Not sure this is the right thing to do. What if its a mixed dav collection that contains not only calendar items but also i.e contacts, warez, whatever. We don't want to be retrieving all items, but just those that are calendar items.

Simon is this correct?

Comment 4

[Simon Vaillancourt]

Comment on attachment 460550 [details] [diff] [review]
removes all usage of the getcontenttype tag to filter out calendar events

I agree with Philipp, I think we would get better interop with validating the contenttype, CalDAV RFC 4791 section 4.2 is pretty clear about calendar collections only containing calendar object resources and dav collection resources so in *theory* we should only need to check the resource type to be NOT a collection. But in practice I think many caldav servers allow any kind of resources to be put in a calendar collection. 

I think the first proposed patch adding an exception for text/plain (With a clear comment) is the best one for interoperability.. Note that we should also test to see what happens when a non-calendar resource with a text/plain content type is loaded (Should be dropped with maybe a warning in the error console?)

Comment 5

[Nathaniel Madura]

<quote>
But in practice I think many caldav servers allow any kind of
resources to be put in a calendar collection. 
<quote>
do you have any evidence of this?

The RFC says that calendar collections should only contain calendar objects. 

The RFC says nothing about Content-Type being appropriately set. 

It seems to me that you are more likely to run into a problem with the content-type not being set properly than you are to run into a problem with receiving non-calendar objects. 

You have evidences that shows you have already had problems with relying on content-type at least 3 times.

At the point of this patch you are only determining whether or not to request additional resources. Later on the code makes a CalDAV specific request in order to actually retrieve the data, requesting the prop calendar-data. My guess is that the server should handle the error for a request on calendar-data that is not actually calendar-data!

Comment 6

[Etienne URBAH]

I fully confirm this bug for Lightning on Fedora 15 :
-  I have a CalDAV calendar on an iCal server,
-  Lightning 1.0b7 on MS-Windows XP SP3 displays and updates it correctly,
-  Lightning on Fedora 15 displays absolutely NO event (old or recent) of this calendar.

This bug is BLOCKING my ability to manage a unified calendar at work and at home.

Comment 7

[Philipp Kewisch [:Fallen][📱📆]]

I'm going to piggyback a fix for this to bug 695117