Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[RFC] handling of broken icals #174

Open
geier opened this issue Dec 8, 2015 · 5 comments
Open

[RFC] handling of broken icals #174

geier opened this issue Dec 8, 2015 · 5 comments

Comments

@geier
Copy link
Collaborator

geier commented Dec 8, 2015

I would like to introduce some kind of handling of for broken/invalid icalendar files and would like your input on how to build this feature.

Some ideas off the top of my head:

three different (possible) modes:

  • ignore [default]: just ignore every error (as we do currently)
  • raise an exception the first time an invalid component is discovered
  • collect all invalid component properties, add a broken or valid property to each component
@stlaz
Copy link
Collaborator

stlaz commented Dec 11, 2015

It seems that the third option is the closest to the solution they use in libical where components consist of lists of properties. If an error occurred during parsing they add an error property accordingly.

See https://github.com/libical/libical/blob/master/src/libical/icalparser.c#L562.

stlaz added a commit to stlaz/icalendar that referenced this issue Dec 18, 2015
@stlaz
Fixes bug when date-time is recognized as time
0555aa8 
Date-time was recognized incorrectly as a date or time. This resulted
in wrong representation of some iCalendar strings.

Also adds "errors" list in Component for saving error strings from parsing.

collective#174
collective#168
@stlaz stlaz mentioned this issue Dec 18, 2015
Merged
stlaz added a commit to stlaz/icalendar that referenced this issue Dec 18, 2015
@stlaz
Fixes bug when date-time is recognized as time
118169d 
Date-time was recognized incorrectly as a date or time. This resulted
in wrong representation of some iCalendar strings.

Also adds "errors" list in Component for saving error strings from parsing.

collective#174
collective#168
stlaz added a commit to stlaz/icalendar that referenced this issue Dec 18, 2015
@stlaz
Fixes bug when date-time is recognized as time
70a7b5a 
Date-time was recognized incorrectly as a date or time. This resulted
in wrong representation of some iCalendar strings.

Also adds "errors" list in Component for saving error strings from parsing.

collective#174
collective#168
@thet
Copy link
Member

thet commented Jan 14, 2016

I your option 3 and the approach of @stlaz . I think this is fixed by: #175 - if you diagree, please repoen.

stlaz added a commit to stlaz/icalendar that referenced this issue Aug 12, 2016
@stlaz
Improvement to error handling
e49fc98 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
collective#158

Improves
collective#174
stlaz added a commit to stlaz/icalendar that referenced this issue Aug 12, 2016
@stlaz
Improvement to error handling
c01d381 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
collective#158

Improves
collective#174
stlaz added a commit to stlaz/icalendar that referenced this issue Sep 8, 2016
@stlaz
Improvement to error handling
9c5de10 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
collective#158

Improves
collective#174
stlaz added a commit to stlaz/icalendar that referenced this issue Sep 13, 2016
@stlaz
Improvement to error handling
b257aa5 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
collective#158

Improves
collective#174
stlaz added a commit to stlaz/icalendar that referenced this issue Jul 20, 2017
@stlaz
Improvement to error handling
43bdc34 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
collective#158

Improves
collective#174
thet pushed a commit that referenced this issue Oct 13, 2021
@stlaz @thet
Improvement to error handling
703a91c 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
#158

Improves
#174
thet pushed a commit that referenced this issue Oct 15, 2021
@stlaz @thet
Improvement to error handling
aa9860d 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
#158

Improves
#174
thet pushed a commit that referenced this issue Oct 15, 2021
@stlaz @thet
Improvement to error handling
97c2ce3 
Previously, if error occured during the creation of inner
type instance from iCalendar string, the error with the
name of the bogus property would be stored in the
appropriate component's errors attribute along with the error
string  but the property's value would be removed from the
parsed representation. This patch keeps the value even with its
parameters at that certain property, the value's type is changed
to vText.

Should allow implementation of
#158

Improves
#174
@jacadzaca jacadzaca mentioned this issue Aug 31, 2022
Closed
@niccokunzmann
Copy link
Member

@geier, now, there is some kind of recognition of broken ical files. Would you close this or could you specify closing critaria?

@niccokunzmann
Copy link
Member

I commented here: #315 (comment) - I would do both - add a broken/valid property and not raise an exception but a warning.

@geier
Copy link
Collaborator Author

geier commented Oct 19, 2022

I don't really care about this issue, but we probably still should implement the suggested features (warnings and some kind of validate function).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@thet @geier @niccokunzmann @stlaz