Why?
Short answer: dokuwiki and DokuWiki are - usually - two separate folders and you should *never* mix them.
That being said: The calendar uses some internally defined variable (DOKU_BASE) to determine the URL it needs to retrieve calendar pages from. This variable is initialized based on the folder name on the file system and thus uses only one of the two names. I assume that later on a CSRF check fails because the paths do not match.
Could you check whether inserting a link using the link wizard in the edit page dialog works? The link wizard uses a very similar logic to retrieve the pages to link to.
Sorry, I've forgotten to write that we are using IIS. You are right, DokuWiki and dokuwiki are separate folders – on UNIX systems. But using IIS on Windows Server, both names refer to the same directory. Therefore, we are able to use both styles. It works with all pages except pages using davcal.
I've tried to insert a link using the link wizard. It doesn't matter if the link contains DokuWiki or dokuwiki.
OK, then my theory is probably wrong :(
I would like to investigate this, but I do have neither Windows nor IIS - do you think you could create a (limited) account for me or a public page with a calendar so I can check at least the requests the browser sends? An empty calendar would be OK.
Unfortunately, that's not possible. We are using DokuWiki in our Intranet. Access from outside isn't possible.
Then we need to go the more complicated route and I have to ask for more details:
Thanks - DokuWiki thinks the request is a CSRF attack. The reason is that some requests are performed to your uppercase URL and some to your lowercase URL. I suppose that IIS invokes separate PHP instances for the different URLs and thus the security tokens do not match.
IMHO this is not a bug. I would try to use some rewrite rules to redirect all requests from DokuWiki to dokuwiki or some other fancy configuration changes to fix this issue on your side.