[Cosmo-dev] Bad ICS already extant
randy at osafoundation.org
Thu Feb 1 09:34:15 PST 2007
Jared Rhine wrote:
> Randy's r3540 says:
> * Perform additional validation on Calendar object by
> validating serlialized Calendar can be parsed again. We
> ran into a problem where bad .ics was allowed into db,
> messing everything up. There is an inconsistency in
> ical4j's validate() and parsing (validate() says its ok
> but parsing barfs.) The idea is to never allow bad .ics
> into the db.
> What can we do about bad data already in the database? This seems to
> affect the data migration process. These ICS resources seem to have
> gotten into and out of 0.5 ok, as these real-world calendars have been
> in daily use, so something during 0.6 development got more restrictive?
The change in 0.6 is that once the initial .ics was stored, subsequent
updates using the internal Cosmo api's didn't do a full parse, only a
Calendar.validate(). It turns out ical4j's Calendar.validate() was
returning true for something that the CalendarParser didn't like. This
meant bad .ics was getting into the db. I added the additional parse
check to prevent this, but it shouldn't effect 0.5 data as that data has
already run through parse().
> (I'm a little concerned about interoperability, as there is bad ICS
> out there in the real-world, no doubt. Now, there will be some
> resources that Cosmo can't store; instead an error will be returned,
> right? Which error, btw; will there be a way to quantify the number
> of resources being rejected from say the logs?)
Yes, a 400 Bad calendar objetct error should be returned.
> How does this interact with Chandler's behavior during publishing?
> Presumably Chandler allowed this data and submitted it during
> publication, and may do so again. Will publication of collections
> containing such resources fail or just some events not succeed?
It depends, if you are talking about the old Chandler publish than if
Chandler submits bad .ics then it will fail. If you are talking about
morse code, then this doesn't apply because there is no .ics being
More information about the cosmo-dev