@rfc2822 thanks again
Creating/editing events no longer works for Fastmail
Can you please post the whole exception + VEVENT.
I could verify that. Yes, those lines seem to cause the 403. Do you have an idea why?
I see a similar issue, although not with the FastMail backend. I think there may be a regression: davx at version 3.3.3-ose work correctly, and you confirmed that it fails at 3.3.4-ose. Thank you.
I see a similar issue, although not with the FastMail backend.
But with which one?
I think there may be a regression: davx at version 3.3.3-ose work correctly, and you confirmed that it fails at 3.3.4-ose. Thank you.
I’d like to know why these two lines cause servers to return 403 instead of randomly patching them out of the new timezone definitions (DAVx4 3.3.4 includes ical4j 3.0.20 which comes with updated timezone definitions).
I too have this issue with the error code 403.
Cyrus Imap/Fastmail use libical to validate, whether the uploaded data is valid. libical says, rather unintentionally, that at most one X- property can be set in the VTIMEZONE component.
This is addressed at https://github.com/libical/libical/pull/446 .
Thanks for finding this out.
Recently I’m working on generating the sent
VTIMEZONEs from the Android time zone definitions instead of the ical4j ones (for various reasons), but there’s no time for that now. So I guess patching those X- lines out will be the most efficient solution for the next release (and of course it’s always a client issue and users expect the client to be fixed).
(Luckily, this particular problem does not affect Google Play users, because Google has locked them to 3.3.3 for an unknown amount of time, and 3.3.3 still uses ical4j 3.0.19.)
Should be worked around with https://gitlab.com/bitfireAT/ical4android/-/commit/267765611efdeb610493851d72f60d629ba8dc01.
I’ll prepare a 3.3.5 soon.
(Discussion about RFC 7809 moved to another thread.)
I can confirm that 3.3.5 from F-Droid no longer has this issue. Thanks for the quick turnaround!