I have created a better workaround than killing the If-Match header using nginx’s java script module:

load_module /usr/lib/nginx/modules/ngx_http_js_module.so; http{ js_import filter from /etc/nginx/filter.js; ... server { ... location ^~/SOGo { js_body_filter filter.filterBody; js_header_filter filter.filterHeader; ... proxy_set_header Accept-Encoding "identity"; ... } }

filter.js:

var body = new Array(); var newBodyLength = null; function filterBody(r, data, flags){ body.push(data); if (flags.last){ data = body.join(''); data = data.replace(//g, ''); newBodyLength = data.length; r.sendBuffer(data, flags); } } function filterHeader(r){ r.headersOut['Content-Length'] = newBodyLength; } export default {filterBody, filterHeader};

Rest of the config is pretty much what you can find in the SOGo wiki.

The performance is probably horrible and I don’t know anything about potential security implications of this solution, but it seems to work. YMMV.

This was inspired by this post: https://forums.bitfire.at/post/14422

There is a already a Nextcloud Server Issue.

@soapernet said in CardDAV - Couldn't apply batch operation:

@rfc2822 Thank you for your message.
Yeah! it’s working!
It’s was simply the ’

You rocks!
Thank you!

Good to hear 🙂 I guess we should change DAVx⁵ so that it doesn’t allow quotation marks in account names (even although it should work).

Hi,

The ICS sources are available here : https://www.data.gouv.fr/fr/datasets/le-calendrier-scolaire/ and the links I tried to use are https://fr.ftp.opendatasoft.com/openscol/fr-en-calendrier-scolaire/Zone-B.ics

This feed contains invalid data:

DTSTAMP:20211001T010008Z DTSTART;VALUE=DATE:20220707 DTEND: ← no value, invalid! SUMMARY:Vacances d'Été LOCATION:Zone B

Also, the events don’t have an UID, so all events must be re-synced at every sync. I recommend to contact the vendor to fix these problems:

invalid DTEND entry missing UIDs of events

You can also check with https://icalendar.org/validator.html to see the problems.

@arwie Similar workaround for nginx here:
https://forums.bitfire.at/post/14584

We’re received this reply from the Synology dev team:

Thank you for the listed points at the point.
The behavior is known to our development and a solution regarding this is being worked on.
Unfortunately, I cannot tell you from our side when exactly there will be a solution, as we have no insight into the development processes.

@computingfroggy Thanks for the update. Good to hear that it now works!

As I understand it, this is clearly a Google Calendar problem. We could introduce ugly and cumbersome workarounds (like faking a new main event with RDATEs for all instances) for this; but these events as given are not valid. The same behavior would at the latest with CalDAV and r/w calendars cause problems and unsyncable events. Also, I have never seen it from any other client or server.

Do you know whether other iCalendar clients (like Thunderbird, Evolution, Outlook…) can understand these events?

Do you know where to report Google Calendar problems?

@rfc2822 fantastic, let’s cross our fingers then 😁

@rfc2822 said in Assigning pictures to Yandex contacts:

Before introducing complicated workarounds, I’d ask Yandex first.

A single boolean flag with “don’t exchange pictures/ignore server-supplied picture” semantics hardly qualifies as a “complicated workaround”. (Basically, “don’t use PHOTO field”.)

As for asking Yandex… I have. And all I got from them so far is a pair of links: one to their official CardDAV/CalDAV setup page, another - to 4pda.ru forum. Not exactly useful.

On the subject of complicated workarounds… A complicated workaround would be to store the encoded picture in the NOTE field of the contact card (with some additional markup, of course) and send it to Yandex that way. I tried and it appears that Yandex servers accept it, store it and then serve it back in its unspoiled form. So, that would actually work around Yandex refusal to store PHOTO… until they get wise to it, probably 🙂

@hexado @hexado said in Posteo X-JABBER:

Sorry for the multiple replies, but actually I was wrong on a couple things in my last post. It looks like the stock Android Contacts app exports as X-JABBER

Yes, the Android Contacts app exports vCard 2.0 (CardDAV requires vCard 3 or 4), and even a very “special” flavor of it. As I see it, these exported files can only be used for importing into Android Contacts again. I recommend to not use these exported files for anything else than for importing with the same app.

but the OS in general uses a different DB format and Conversations does work with DAVx5 / IMPP.

Works here, too. I use Conversations and XMPP addresses for contacts myself.

I continue to have to have the problem of phone numbers edited Android-side disappearing in Posteo on sync back. Edited emails don’t have this problem. Also, this occurs when using IMPP:xmpp:j@j.com as suggested

I have checked this and found:

TYPE=MOBILE is not defined, neither in vCard 3 nor 4. So for DAVx⁵, this is a custom label, so it saves the phone number with “type: custom” and custom label: “Mobile”. When you edit the phone number on Android without changing the type, DAVx⁵ sends the phone number as: group1.TEL;TYPE=x-mobile:34243451343 group1.X-ABLabel:Mobile

using the X-ABLabel to retain the label.

However, it seems the Posteo Web UI doesn’t understand vCard-compliant grouping and simply doesn’t show the phone number. If you then change the type to “Mobile” (not Custom: mobile) on Android and then sync, DAVx⁵ will upload TEL;TYPE=cell:.. and the phone number will be shown in Posteo as expected.

So:

Can you please report the missing grouping support to Posteo? Please fix your vCards so they use TYPE=cell instead of TYPE=mobile, or you risk that things like this happen.

@sant Yes:

Unselect the calendar in DAVx⁵. Force sync. Select the calendar again and choose “Force read-only” if you want the calendar to be read-only even when the server says its read-write. Sync again.

@rfc2822 Thank you, this helps a lot, it is a subscription of a shared calendar of an openXchange suite. Seems this error has always been there, but ICSX5 has begun to fail just with the pre-former release. I will contact the server software provider…

I can confirm that 3.3.5 from F-Droid no longer has this issue. Thanks for the quick turnaround!

@mbiebl Yes, this has been fixed with Google Contacts 3.39. We’ll keep the page a bit for users who don’t update often, and then remove it.

@mikescandy Great that you found it anyway 🙂

As I understand it, it’s an eM Client problem, because it treats LABEL as a separate address. Please follow up here: https://forum.emclient.com/t/contacts-wont-display-address-in-column-when-vcard-uses-lower-case-type/45285/7

So, the Nokia support replies and said that this is an App issue of DAVx5 but I have to wait for future Updates of the Phone too 😵 The support isn´t good and the 7.2 is a buggy phone with a lot of problems. All updates and patches bringing new problems. I decided to send it back and buy another phone. I hope this will help.

I have added it to “Known problems” here, too: https://www.davx5.com/tested-with/icloud

Until this is fixed in the server, we have added a workaround which is shipped with DAVx5 3.1-rc1 (latest beta on Google Play). Does it work for you with 3.1-rc1 again?