Inf-IT DAV Clients

davclients@lists.inf-it.com

313 discussions

mailing list archive
by Ján Máté 04 Jul '13

04 Jul '13

Hi all, mailing list archive is now public and available at: http://www.inf-it.com/mlmmj/davclients/ JM p.s.: the archive is updated hourly

1 0

Re: Bug in CalDav-Sync with deletion of repeating events
by Marten Gajda 02 Jul '13

02 Jul '13

Hi Felix, I hope you don't mind that I include the CalDavZAP mailing list (I've BBC'ed you). The problem is that Android doesn't actually delete instances of a recurring event. Instead Android creates an exception and sets the status to "cancelled". My app synchronizes the event just like that. The app could try to fix that automatically, but I think converting a "cancelled" exception to a deleted event would be wrong. The app should sync events, not modify them. What you see in CalDavZAP is a bug in the exception handling of CalDavZap. I've attached an event that shows the problem. It's a recurring event (it recurs every Tuesday, Wednesday and Thursday). The instances on 2013-07-03 and 2013-07-04 have been deleted in Android, i.e. their status is set to "CANCELLED". CalDavZap shows the original event + the exceptions. I think the correct behavior would be to show the exception crossed out. That's what most clients to with cancelled events. cheers Marten Am 02.07.2013 13:14, schrieb Felix: > Hi there, > > i am using caldav-sync on cyanogenmod 10.1 with an davical-server > 1.1.1-1 on debian and caldavzap as web-frontend. > When i have a repeating event and delete one occurence of it in android, > caldavzap still shows the deleted event in addition to a clone of the > event without repeatitions. Android does not show these events. > > Best regards, > Felix -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten(a)dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten(a)dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391

2 1

CardDavMATE 0.11.0 and CalDavZAP 0.9.0
by Ján Máté 01 Jul '13

01 Jul '13

Hi everybody, CardDavMATE 0.11.0 and CalDavZAP 0.9.0 are released. Changelog: http://www.inf-it.com/carddavmate/changelog.txt http://www.inf-it.com/caldavzap/changelog.txt Download: http://www.inf-it.com/CardDavMATE_0.11.0.zip http://www.inf-it.com/CalDavZAP_0.9.0.zip Many thanks for your feedbacks and bugreports! JM

4 10

CalDavZAP 0.9.0rc2
by Ján Máté 28 Jun '13

28 Jun '13

Hi all, here is the version which fixes the "hanging" loader problem: http://www.inf-it.com/CalDavZAP_0.9.0rc2.zip demo: http://www.inf-it.com/caldavzap-next/ changelog: http://www.inf-it.com/caldavzap-next/changelog.txt JM

4 10

Re: [Inf-IT DAVcl] Access-Control-Expose-Headers
by Ken Murchison 29 May '13

29 May '13

Hi Ján, I think I understand what my server needs to do as you outline below. Here is an actual (partial) response to a preflight PUT request from CalDavZap: Access-Control-Max-Age: 3600 Access-Control-Allow-Headers: authorization,content-type,if-none-match,x-client Access-Control-Allow-Methods: OPTIONS, GET, HEAD, PUT, DELETE Access-Control-Allow-Methods: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK Access-Control-Allow-Origin: http://localhost Access-Control-Allow-Credentials: true What I'm asking is if your client would like to get the ETag from the response to the actual PUT, would the browser allow it? Do I need to include Access-Control-Expose-Headers: ETag to allow it? The reason I ask this particular question is that your client does a calendar-multiget REPORT immediately following the PUT asking for the getetag and calendar-data properties. Are you doing this because this is the only way to get the ETag, or do you want to make sure that the calendar-data is the same as what you PUT, or both? Obviously, the ETag should be available in the PUT response and if you use the Prefer:return=representation header, the server might also give you the calendar-data in the PUT response body saving a round-trip. See draft-snell-http-prefer <http://datatracker.ietf.org/doc/draft-snell-http-prefer/> and draft-murchison-webdav-prefer <http://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/> On 05/29/2013 11:19 AM, Ján Máté wrote: > Hi Ken, > > the problem is not as simple as it looks like. We cannot use "simple" headers, because if a browser detects any cross-domain query (different protocol/domain or port), it will make a "preflight" OPTIONS request and if there are no proper CORS headers in the response, the browser will refuse to make the real request (from JavaScript). There is no way to disable these preflight requests (these are generated internally by browsers). > > Correct CORS headers for CardDavMATE/CalDavZAP looks like: > > Access-Control-Allow-Origin * > => everybody can make request to this server > > Access-Control-Allow-Methods GET,POST,OPTIONS,PROPFIND,REPORT,PUT,MOVE,DELETE,LOCK,UNLOCK > => all allowed methods (even if you return something like "unsupported" or "not implemented" for some of them) > > Access-Control-Allow-Headers User-Agent,Authorization,Content-type,Depth,If-match,If-None-Match,Lock-Token,Timeout,Destination,Overwrite,X-client,X-Requested-With > => all standard headers used by dav clients/browsers (sometime you need to add another one for new client ... so it is good to have a configuration option for additional headers) > > > JM > > > On May 29, 2013, at 4:28 PM, Ken Murchison<murch(a)andrew.cmu.edu> wrote: > >> Ján, >> >> I'm adding support for CORS requests to my server and I'm wondering if there any response headers that you need/want exposed. I'm not familiar with XMLHttpRequest so I don't know what you have access to normally. Non-simple response headers that I think might be useful: >> >> Accept-Ranges >> Content-Encoding >> Content-Location >> DAV >> ETag >> Lock-Token >> Preference-Applied >> Schedule-Tag >> >> >> Right now, your client works fine without Access-Control-Expose-Headers in the response, but I'm just trying to future-proof my code. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

Access-Control-Expose-Headers
by Ken Murchison 29 May '13

29 May '13

Ján, I'm adding support for CORS requests to my server and I'm wondering if there any response headers that you need/want exposed. I'm not familiar with XMLHttpRequest so I don't know what you have access to normally. Non-simple response headers that I think might be useful: Accept-Ranges Content-Encoding Content-Location DAV ETag Lock-Token Preference-Applied Schedule-Tag Right now, your client works fine without Access-Control-Expose-Headers in the response, but I'm just trying to future-proof my code. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ken Murchison 29 May '13

29 May '13

OK. But you still haven't bumped them up to 0.9 and 0.11 respectively. Or do you plan to do that when you actually release them? On 05/29/2013 10:59 AM, Ján Máté wrote: > These version numbers are "OK" because we have no support for "beta/rc" version comparison. So every beta/rc release is always numbered: > > *.42 > > http://en.wikipedia.org/wiki/42_(number) > > :-) > > > JM > > On May 29, 2013, at 4:14 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> On 05/21/2013 04:19 PM, Ján Máté wrote: >>> Hi everybody, >>> >>> new release candidates: >>> >>> http://www.inf-it.com/CardDavMATE_0.11rc4.zip >>> http://www.inf-it.com/CalDavZAP_0.9rc4.zip >> FYI. The version info in the X-Client request headers isn't up to date. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ken Murchison 29 May '13

29 May '13

On 05/21/2013 04:19 PM, Ján Máté wrote: > Hi everybody, > > new release candidates: > > http://www.inf-it.com/CardDavMATE_0.11rc4.zip > http://www.inf-it.com/CalDavZAP_0.9rc4.zip FYI. The version info in the X-Client request headers isn't up to date. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Discovery Via PROPFIND
by Jim Seymour 28 May '13

28 May '13

From another thread... On Mon, 20 May 2013 07:17:56 -0400 Ken Murchison <murch(a)andrew.cmu.edu> wrote: [snip] > > BTW, rather than having the admin specify the path to user principals > in config.js, you should look into doing your discovery by doing a > PROPFIND on /.well-known/caldav for DAV:current-user-principal, and > following any redirects. See http://tools.ietf.org/html/rfc6764 > What are the odds of this happening? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ján Máté 21 May '13

21 May '13

Hi everybody, new release candidates: http://www.inf-it.com/CardDavMATE_0.11rc4.zip http://www.inf-it.com/CalDavZAP_0.9rc4.zip RC3 -> RC4 changes: - XML requests cleanup (both clients) - added "loader" and "error" icons to the CardDavMATE resource list - CalDavZAP support for additional servers - removed obsolete functions from CalDavZAP - fixed problem with delete operation in CardDavMATE (workaround for jQuery 2.0.0 and missing reponseXML property) - proper processing of addressbook-home-set and calendar-home-set - updated IANA timezone database + related changes/fixes - removed TRANSP property from Todos JM

1 0

← Newer
1
...
24
25
26
27
28
29
30
31
32
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients