Inf-IT DAV Clients May 2013

davclients@lists.inf-it.com

4 participants
24 discussions

by Ján Máté

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

10 years, 2 months

Re: [Inf-IT DAVcl] Access-Control-Expose-Headers

by Ken Murchison

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

10 years, 3 months

Access-Control-Expose-Headers

by Ken Murchison

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

10 years, 3 months

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4

by Ken Murchison

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

10 years, 3 months

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4

by Ken Murchison

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

10 years, 3 months

Discovery Via PROPFIND

by Jim Seymour

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>.

10 years, 3 months

CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4

by Ján Máté

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

10 years, 4 months

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available

by Ken Murchison

Actually, my power went out. I will let you know when I'm back up and running. On 5/20/2013 9:13 AM, Ján Máté wrote: > Hi Ken, > > looks like you forgot to disable your firewall. I tried to connect > from two different networks and then also using telnet: > > telnet ksmurchison.dyndns.org <http://ksmurchison.dyndns.org> 443 > Trying 76.180.197.142... > telnet: connect to address 76.180.197.142: Network is unreachable > telnet: Unable to connect to remote host > > > > JM > > > On May 20, 2013, at 1:17 PM, Ken Murchison <murch(a)andrew.cmu.edu > <mailto:murch@andrew.cmu.edu>> wrote: > >> OK, the quickest way for me to do this was to give you a test account >> on my home dev machine: > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

10 years, 4 months

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available

by Ken Murchison

On 05/20/2013 02:17 AM, Ján Máté wrote: > On May 20, 2013, at 2:50 AM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> I applied the caldavzap patch and the client got further along. It sees my calendars but spins trying to load them. The last request that I see if a sync-collection report. I can send telemetry of the request in the morning if you like. I *might* be able to get you access to a test account. > The fastest way to find the root of the problem is a test account. OK, the quickest way for me to do this was to give you a test account on my home dev machine: host: https://ksmurchison.dyndns.org/dav/principals/user/test01/ passwd: test01 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

10 years, 4 months

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available

by Ken Murchison

I applied the caldavzap patch and the client got further along. It sees my calendars but spins trying to load them. The last request that I see if a sync-collection report. I can send telemetry of the request in the morning if you like. I *might* be able to get you access to a test account. On 05/19/2013 05:10 PM, Ján Máté wrote: > Hi Ken, > > XML requests cleanup patches for RC3 (for CardDavMATE there are also few very minor changes): > > http://www.inf-it.com/fixes/caldavzap_0.9rc4x.diff > http://www.inf-it.com/fixes/carddavmate_0.11rc4x.diff > > Please report whether these patches solve your problem. > > > JM > > > On May 19, 2013, at 7:51 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Just started testing this release, and found the following PROPFIND request: >> >> <?xml version="1.0" encoding="utf-8"?><D:propfind xmlns:x3="http://apple.com/ns/ical/" xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><x3:calendar-color/><D:current-user-privilege-set/><D:max-image-size xmlns:Dd="urn:ietf:params:xml:ns:carddav"/><D:displayname/><D:resourcetype/><D:supported-report-set/><B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/><B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/><D:sync-token/></D:prop></D:propfind> >> >> >> - You declare the caldav namespace globally (prefixed by 'C'), but then you redeclare it locally in supported-calendar-component-set (prefixed by 'B'). This is confusing my server (which is a bug on my part), but it seems to be extra unnecessary bits on the wire. >> >> - There is no standard caldav property named supported-calendar-component-sets (plural). Are you expecting this from some server or is it a typo? v0.9rc3 isn't showing any of my calendars and I'm wondering if this is the reason. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

10 years, 4 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients May 2013