Hi,
On Feb 12, 2013, at 10:31 PM, Sven Anders anders@anduras.de wrote:
I think I configured it correctly. Here the headers:
OPTIONS /caldav.php/ HTTP/1.1 Host: caldav.hannover.anduras.office User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Origin: http://calendar.hannover.anduras.office Access-Control-Request-Method: PROPFIND Access-Control-Request-Headers: authorization,content-type,depth,x-client Connection: keep-alive
HTTP/1.1 200 OK Date: Tue, 12 Feb 2013 21:13:30 GMT Server: Apache/2.2.22 (Ubuntu) Access-Control-Allow-Origin: http://calendar.hannover.anduras.office, http://calendar, http://addressbook.hannover.anduras.office, http://addressbook Access-Control-Allow-Methods: GET,POST,OPTIONS,PROPFIND,REPORT,PUT,MOVE,DELETE,LOCK,UNLOCK 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 access-control-allow-credentials: true Content-Length: 618 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1
Do you see anything wrong here?
Yes - it is wrong. You cannot use Access-Control-Allow-Origin with multiple origins separated by comma ... if you really need to allow multiple origins, you need to define them separately:
.... Header always set Access-Control-Allow-Origin http://calendar.hannover.anduras.office Header always set Access-Control-Allow-Origin http://calendar Header always set Access-Control-Allow-Origin http://addressbook.hannover.anduras.office Header always set Access-Control-Allow-Origin http://addressbook ....
** Some more questions:
CalDavZap
- How do I add calenders of other people?
a.) both globalAccountSettings and globalNetworkAccountSettings allows you to define an array of accounts b.) both globalAccountSettings and globalNetworkAccountSettings allows you to define an array of additionalResources for each account c.) globalNetworkAccountSettings with auth module allows you to define any configuration dynamically (in the auth module itself) d.) you can use the delegation option (in globalAccountSettings, globalNetworkAccountSettings and also the combination of the globalNetworkAccountSettings and the auth module)
it the config.js there are a ton of comments (with examples) for each of these options ... currently the config.js (with combination of the changelog.txt) is the "best" documentation ;-)
- Is it possible to change the calendar color?
no, CalDavZAP reads the calendar color from the server (it is stored by Apple clients as a property - "http://apple.com/ns/ical/calendar-color") ... if there is no such property on the server then CalDavZAP generates a color from the calendar URL (so it is always the same, but you cannot change it in the client itself)
- Is it possible to hide completed TODOs?
currently you can use the globalTodoHideExpired option (see config.js) ... but in 0.9 we will add a completely new interface for TODO with lot of new options (0.9 is coming in ~3 weeks)
CardDavMate
- How do I create Groups?
this feature is supported ONLY by Apple clients (there is no resource/collection management in the current version of CardDavMATE/CalDavZAP) ... but CardDavMATE has full read-write support for vCard groups (if these are already defined)
- Is it possible to filter by categories?
directly not, but you can use the search box
** Some ideas for usability:
CardDavMate
- Make the image (in edit mode) clickable and show a upload window.
this feature is already on my roadmap
- Autocomplete for already used categories or display select list/box.
this feature is already present ... if you start to write the category name you will see a listbox for categories with similar names ... you can also press the "down" button on your keyboard to see all currently present categories
JM
Am 12.02.2013 23:16, schrieb Ján Máté:
Hi,
Thanks for the answers!
Access-Control-Allow-Origin: http://calendar.hannover.anduras.office, http://calendar, http://addressbook.hannover.anduras.office, http://addressbook
Do you see anything wrong here?
Yes - it is wrong. You cannot use Access-Control-Allow-Origin with multiple origins separated by comma ... if you really need to allow multiple origins, you need to define them separately:
.... Header always set Access-Control-Allow-Origin http://calendar.hannover.anduras.office Header always set Access-Control-Allow-Origin http://calendar Header always set Access-Control-Allow-Origin http://addressbook.hannover.anduras.office Header always set Access-Control-Allow-Origin http://addressbook ....
Ok, I tried:
Header always add Access-Control-Allow-Origin http:/... ^^^ I used add here, not set!
But I does not seem to work. The "W3C Candidate Recommendation" says, it should be possible to use a list separated by spaces, but the "add" command makes a list with commas. Maybe here is the problem. Now it works, thanks!
- Autocomplete for already used categories or display select list/box.
this feature is already present ... if you start to write the category name you will see a listbox for categories with similar names ... you can also press the "down" button on your keyboard to see all currently present categories
Ok, I missed that. But I found a bug here. You can remove categories, even, if you are not in the edit mode.
I have a problem adding static .ics calendars.
I configured:
var thisyear = new Date().getFullYear(); var globalSubscribedCalendars={hrefLabel: 'Externe', showHeader: true, calendars: [{displayName: 'Feiertage', href: 'http://www.mozilla.org/projects/calendar/caldata/GermanHolidays.ics', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AACCAA'}, {displayName: 'Ferien '+thisyear, href: 'http://www.schulferien.org/iCal/Ferien/icals/Ferien_Niedersachsen_%27+thisye...', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AAAACC'} ]};
The calendar is queried:
OPTIONS /iCal/Ferien/icals/Ferien_Niedersachsen_2013.ics?_=1360831644748 HTTP/1.1 Host: www.schulferien.org [...]
But the answer is empty:
HTTP/1.1 200 OK Date: Thu, 14 Feb 2013 08:47:24 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS Content-Length: 0 Keep-Alive: timeout=2, max=200 Connection: Keep-Alive Content-Type: text/calendar
The problems seems to be, that the public server only delivers the calendars, if queried with the GET method. I did not found a configuration option to force this... Maybe we should add an option or handle .ics calendars different.
And it would be nice to have an "sync" button. I try with three clients at the same time (Thunderbird, Android and CalDavZap/CardDavMate) and at least in CardDavMate I had problems, because the displayed entries were too old. A login/logout did not help.
Regards Sven
Am 14.02.2013 10:12, schrieb Sven Anders:
Am 12.02.2013 23:16, schrieb Ján Máté:
Hi,
Thanks for the answers!
Access-Control-Allow-Origin: http://calendar.hannover.anduras.office, http://calendar, http://addressbook.hannover.anduras.office, http://addressbook
Do you see anything wrong here?
Yes - it is wrong. You cannot use Access-Control-Allow-Origin with multiple origins separated by comma ... if you really need to allow multiple origins, you need to define them separately:
.... Header always set Access-Control-Allow-Origin http://calendar.hannover.anduras.office Header always set Access-Control-Allow-Origin http://calendar Header always set Access-Control-Allow-Origin http://addressbook.hannover.anduras.office Header always set Access-Control-Allow-Origin http://addressbook ....
Ok, I tried:
Header always add Access-Control-Allow-Origin http:/... ^^^ I used add here, not set!
But I does not seem to work. The "W3C Candidate Recommendation" says, it should be possible to use a list separated by spaces, but the "add" command makes a list with commas. Maybe here is the problem. Now it works, thanks!
Ok, this was too fast!
It worked, because I accessed the last entry in the list. If I try any of the other domains it does not work. I seems, that only one entry is allowed and the browser uses the last entry, if you have multiple given.
At the moment I must use "*"...
Maybe anybody other has an idea?
Regards Sven
Hi,
On Feb 14, 2013, at 10:12 AM, Sven Anders anders@anduras.de wrote:
Ok, I missed that. But I found a bug here. You can remove categories, even, if you are not in the edit mode.
I have a problem adding static .ics calendars.
I configured:
var thisyear = new Date().getFullYear(); var globalSubscribedCalendars={hrefLabel: 'Externe', showHeader: true, calendars: [{displayName: 'Feiertage', href: 'http://www.mozilla.org/projects/calendar/caldata/GermanHolidays.ics', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AACCAA'}, {displayName: 'Ferien '+thisyear, href: 'http://www.schulferien.org/iCal/Ferien/icals/Ferien_Niedersachsen_%27+thisye...', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AAAACC'} ]};
The calendar is queried:
OPTIONS /iCal/Ferien/icals/Ferien_Niedersachsen_2013.ics?_=1360831644748 HTTP/1.1 Host: www.schulferien.org [...]
We use the GET method ... the OPTIONS is a preflight request sent by your browser because (stupid) jQuery adds some additional headers to request, but CORS allows only "simple headers".
The bad news is that we cannot solve this problem (it is not possible to prevent jQuery to send these headers) :-/ ... So the solution is to copy the ics file to your server (for example by a cron job and wget) or create a simple web server proxy (an URL which redirects you to another server/another URL).
The same bug was reported to jQuery (and they said that it was fixed in 1.5.1, but the current version is still buggy /maybe a returning bug?/): http://bugs.jquery.com/ticket/8423
JM
But the answer is empty:
HTTP/1.1 200 OK Date: Thu, 14 Feb 2013 08:47:24 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS Content-Length: 0 Keep-Alive: timeout=2, max=200 Connection: Keep-Alive Content-Type: text/calendar
The problems seems to be, that the public server only delivers the calendars, if queried with the GET method. I did not found a configuration option to force this... Maybe we should add an option or handle .ics calendars different.
Am 14.02.2013 13:18, schrieb Ján Máté:
Hi,
On Feb 14, 2013, at 10:12 AM, Sven Anders anders@anduras.de wrote:
Ok, I missed that. But I found a bug here. You can remove categories, even, if you are not in the edit mode.
I have a problem adding static .ics calendars.
I configured:
var thisyear = new Date().getFullYear(); var globalSubscribedCalendars={hrefLabel: 'Externe', showHeader: true, calendars: [{displayName: 'Feiertage', href: 'http://www.mozilla.org/projects/calendar/caldata/GermanHolidays.ics', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AACCAA'}, {displayName: 'Ferien '+thisyear, href: 'http://www.schulferien.org/iCal/Ferien/icals/Ferien_Niedersachsen_%27+thisye...', userAuth: {userName: '', userPassword: ''}, ignoreAlarm: true, color: '#AAAACC'} ]};
The calendar is queried:
OPTIONS /iCal/Ferien/icals/Ferien_Niedersachsen_2013.ics?_=1360831644748 HTTP/1.1 Host: www.schulferien.org [...]
We use the GET method ... the OPTIONS is a preflight request sent by your browser because (stupid) jQuery adds some additional headers to request, but CORS allows only "simple headers".
The bad news is that we cannot solve this problem (it is not possible to prevent jQuery to send these headers) :-/ ... So the solution is to copy the ics file to your server (for example by a cron job and wget) or create a simple web server proxy (an URL which redirects you to another server/another URL).
The same bug was reported to jQuery (and they said that it was fixed in 1.5.1, but the current version is still buggy /maybe a returning bug?/): http://bugs.jquery.com/ticket/8423
But the answer is empty:
HTTP/1.1 200 OK Date: Thu, 14 Feb 2013 08:47:24 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS Content-Length: 0 Keep-Alive: timeout=2, max=200 Connection: Keep-Alive Content-Type: text/calendar
The problems seems to be, that the public server only delivers the calendars, if queried with the GET method. I did not found a configuration option to force this... Maybe we should add an option or handle .ics calendars different.
Hmmm?! Copying the .ics file isn't a solution (only a temporary workaround).
But I do not understand. The OPTIONS preflight request succeeded (even if it's empty). So why does it not work? Is a valid answer expected from the preflight request before the GET request is sent? If so, why can we not ignore it? Is this hard coded in jquery?
I did a quick check and the fix from the bug report is still in the code. But I did not find this code anywhere in the used jquery library?!
The comment says: "(it can always be set on a per-request basis or even using ajaxSetup)" Is it turned on anywhere in the code, even if we do not want it here???
Regards Sven
On Feb 15, 2013, at 9:57 AM, Sven Anders anders@anduras.de wrote:
Hmmm?! Copying the .ics file isn't a solution (only a temporary workaround).
But I do not understand. The OPTIONS preflight request succeeded (even if it's empty). So why does it not work? Is a valid answer expected from the preflight request before the GET request is sent? If so, why can we not ignore it? Is this hard coded in jquery?
It not works because the OPTIONS request is send directly by the browser (not jQuery/client). The problem is that if you want to make a cross-domain query you are VERY limited. For example you can make a GET query but ONLY if that query uses "simple headers" (see http://www.w3.org/TR/cors/#simple-header):
A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is anASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.
The first problem is that we use the X-client header (it will be removed in the next version) and also a non-simple content type (also will be fixed in the next version to 'text/plain'). The second problem is, that jQuery adds additional (non-simple) headers and we cannot fix this.
If the browser detects the non-simple header situation (before it makes a request itself) it sends an OPTIONS (preflight) request. The result from this request is handled inside the browser - not Javascript. That request asks the remote server for allowed URLs and allowed headers to make cross-domain requests. And because the Mozilla server not sends the required headers (it is OK), the browser (not jQuery) refuse to make the real GET request.
I did a quick check and the fix from the bug report is still in the code. But I did not find this code anywhere in the used jquery library?!
Maybe because the final code is minified.
The comment says: "(it can always be set on a per-request basis or even using ajaxSetup)" Is it turned on anywhere in the code, even if we do not want it here???
I don't know, if you are interested to fix this problem download the non-minified version of jQuery and try to debug it.
JM
Regards Sven
Am 15.02.2013 11:07, schrieb Ján Máté:
On Feb 15, 2013, at 9:57 AM, Sven Anders <anders@anduras.de mailto:anders@anduras.de> wrote:
Hmmm?! Copying the .ics file isn't a solution (only a temporary workaround).
But I do not understand. The OPTIONS preflight request succeeded (even if it's empty). So why does it not work? Is a valid answer expected from the preflight request before the GET request is sent? If so, why can we not ignore it? Is this hard coded in jquery?
It not works because the OPTIONS request is send directly by the browser (not jQuery/client). The problem is that if you want to make a cross-domain query you are VERY limited. For example you can make a GET query but ONLY if that query uses "simple headers" (see http://www.w3.org/TR/cors/#simple-header):
/*A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is anASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.*/
The first problem is that we use the X-client header (it will be removed in the next version) and also a non-simple content type (also will be fixed in the next version to 'text/plain'). The second problem is, that jQuery adds additional (non-simple) headers and we cannot fix this.
If the browser detects the non-simple header situation (before it makes a request itself) it sends an OPTIONS (preflight) request. The result from this request is handled inside the browser - not Javascript. That request asks the remote server for allowed URLs and allowed headers to make cross-domain requests. And because the Mozilla server not sends the required headers (it is OK), the browser (not jQuery) refuse to make the real GET request.
Ok, I think I understand the problem. But I wonder, that jQuery doesn't allow to make simple queries... But it should be possible to use the plain XMLHttpRequest object, right?
I did a quick check and the fix from the bug report is still in the code. But I did not find this code anywhere in the used jquery library?!
Maybe because the final code is minified.
Yes, I saw this. But I seem to missed the change in the file...
The comment says: "(it can always be set on a per-request basis or even using ajaxSetup)" Is it turned on anywhere in the code, even if we do not want it here???
I don't know, if you are interested to fix this problem download the non-minified version of jQuery and try to debug it.
I'll wait for the next version and try it then...
Regards Sven
Hi,
On Feb 18, 2013, at 7:49 PM, Sven Anders anders@anduras.de wrote:
It not works because the OPTIONS request is send directly by the browser (not jQuery/client). The problem is that if you want to make a cross-domain query you are VERY limited. For example you can make a GET query but ONLY if that query uses "simple headers" (see http://www.w3.org/TR/cors/#simple-header):
/*A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is anASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.*/
The first problem is that we use the X-client header (it will be removed in the next version) and also a non-simple content type (also will be fixed in the next version to 'text/plain'). The second problem is, that jQuery adds additional (non-simple) headers and we cannot fix this.
If the browser detects the non-simple header situation (before it makes a request itself) it sends an OPTIONS (preflight) request. The result from this request is handled inside the browser - not Javascript. That request asks the remote server for allowed URLs and allowed headers to make cross-domain requests. And because the Mozilla server not sends the required headers (it is OK), the browser (not jQuery) refuse to make the real GET request.
Ok, I think I understand the problem. But I wonder, that jQuery doesn't allow to make simple queries... But it should be possible to use the plain XMLHttpRequest object, right?
XMLHttpRequest maybe works (I am not sure because it usually adds something like "requested with" header) but we do not want to maintain a hybrid. We will use jQuery for all request and rather wait for jQuery fix (if it is really fixable).
JM
-
Ján Máté -
Sven Anders