Radicale
Radicale copied to clipboard
Calendar entry can not be moved - error 502
Hey,
first of all thanks for the project.
While using on daily basis we encountered the following error when trying to move a calendar entry from one calendar to another.
„502“
at CalDAVMoveEntityQueueableOperation.
I use radicale on archlinux and the error occurs (reproducable) when trying to move an calendar event from one calendar to another (by double clicking the event and selecting another calendar) and both calendars belong to the same user. I use macos 10.13.5 calendar as a client. To reproduce create a new user in the radicale webinterface and add two or more calendars to the same user. Connect to the user from macos calendar, add a calendar entry to calendar1. Then double click it and select calendar2 of the same user as calendar.
Then an exclamation mark appears in the macos calendar and the above error message appears and asks for retrying or using the server version. Retrying doesn`t help either.
I think this is the corresponding entry from nginx log.
172.16.2.32 - user [24/Jun/2018:11:26:24 +0200] "MOVE /radicale/user/7b82ff2b-efa1-f97f-99cd-c0e380876907/ACE78827-DC36-48E1-8FC1-8295D1D40E69.ics HTTP/1.1" 502 53 "-" "Mac+OS+X/10.13.5 (17F77) CalendarAgent/399.2.2"
As a workaround you can cut the calendar event from calendar1, select calendar2 in the sidebar of the macos calendar app and paste the entry to calendar2. This works without issues.
Would be very nice to see this fixed.
Thanks in advance.
Actually this is a bit weird. I was looking for a solution for longer and now after posting the issue it seems I searched for the right things and with the help of the following "old" issues it seems solved.
https://github.com/Kozea/Radicale/issues/774
https://github.com/Kozea/Radicale/issues/838
My nginx block that seems to be working is now:
location /radicale/ {
proxy_pass https://127.0.0.1:5232/;
proxy_set_header X-Script-Name /radicale;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#proxy_pass_header Authorization;
#set $destination $http_destination;
#if ($destination ~* ^https(.+)$) {
# set $destination http$1;
#}
#proxy_set_header Destination $destination;
proxy_set_header Host $host;
# user authentication
#auth_basic "Login";
auth_basic_user_file /var/lib/radicale/security/.htpasswd_radicale;
# encrypting traffic between radicale and nginx as reverse proxy
proxy_ssl_certificate /var/lib/radicale/reverse_proxy_encryption/client_cert.pem;
proxy_ssl_certificate_key /var/lib/radicale/reverse_proxy_encryption/client_key.pem;
proxy_ssl_trusted_certificate /var/lib/radicale/reverse_proxy_encryption/server_cert.pem;
}
Unfortunately the error is back in version 2.1.10 and could not be fixed with the "old" advices.
It would be nice to see this fixed or if just the nguni config needs another setting it would be nice to have the documentation updated.
Downgrading to radicale version 2.9.1 solves it.
Thanks a lot.
your workaround works for me.
I have tried bypassing nginx, i.e. a direct connection to the radicale server, and this error still persists. I can post debug output, but I am not sure what commands to run.
Can also confirm a regression from 2.1.9 to 2.1.10 , downgrading fixed my problem
Found the reason, Collection.has_uid(self, uid)
method is not defined in the published pip3 package for Radicale 2.1.10
Error Message from Radicale:
Oct 30 21:58:21 naut.ca env[19765]: [7f04888e4700] ERROR: An exception occurred during MOVE request on '/yoonsik/83AC2C70-8766-4EE7-AE69-6E195127B351/FB4D14D2-A735-46CF-B427-941C29FEA85B.ics': 'Collection
Copy' object has no attribute 'has_uid'
Missing function from Collection class, taken from github source:
def has_uid(self, uid):
"""Check if a UID exists in the collection."""
for item in self.get_all():
if item.uid == uid:
return True
return False
Workaround for Debian 9:
sudo nano /usr/local/lib/python3.5/dist-packages/radicale/storage.py
Paste in the above function into the Collection class.
Restart radicale.
After upgrading to 2.1.11 the above setup works again. Thanks for the fix.
I'm using the last version of radicale and I still have this issue.
This is what the debug logs are saying
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] DEBUG: Script name overwritten by client: '/radicale'
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] DEBUG: Sanitized script name: '/radicale'
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] DEBUG: Sanitized path: '/valentin/E041B0B3-94DC-4678-8AE7-C65C33C6D4C6/9B3C4E89-66E7-4906-B6B7-3A178CCE4ECE.ics'
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] INFO: Successful login: 'valentin'
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] INFO: Unsupported destination address: 'https://domain.tld/radicale/valentin/28179b4b-85b2-4790-91e4-6a03c1990263/9B3C4E89-66E7-4906-B6B7-3A178CCE4ECE.ics'
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] DEBUG: Response content:
May 03 12:46:01 panda radicale[590506]: Remote destination not supported.
May 03 12:46:01 panda radicale[590506]: [7fcaea4e6700] INFO: MOVE response status for '/valentin/E041B0B3-94DC-4678-8AE7-C65C33C6D4C6/9B3C4E89-66E7-4906-B6B7-3A178CCE4ECE.ics' in 0.009 seconds: 502 Bad Gateway
this might have to do with me using macOS' Calendar app
@tgy I believe you have a different issue, or at least the error messages seem to be different.
I solved my problem today. I've added proxy_set_header Host $http_host;
to my nginx server configuration. It seems to solve the issue of the HTTP_HOST
header having a localhost:port
value instead of the domain.tld
value.
A sample nginx block for those who may need it:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
ssl_dhparam /etc/ssl/certs/dhparams.pem;
include snippets/lets_encrypt.conf;
server_name davs.naut.ca;
location / {
proxy_pass http://127.0.0.1:5232/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
We still encounter the 502 error when moving events from one calendar to another (yes locally within the same collection). URLs and UUIDs all seem to be valid, readable by the user _radicale (we don't start the server with root rights) and other features work as expected. We tried 2.1.12 as OpenBSD package as well as 3.1.7 installed manually on OpenBSD 7.0 with Apache httpd: IP version 4 (no v6), port 80 only for Let's Encrypt, port 443 as proxy to localhost:5232, all behind a NAT Router with dynDNS and port forwarding to a virtual machine. The actual log at debug level reads:
[2022-06-23 17:02:31 +0200] [8927/Thread-568] [INFO] MOVE response status for '/username/35CA95B0-687C-498A-8D84-0A3FDD7E5870/DD9330C4-9C81-432F-9762-63372C39D0B6.ics' in 0.003 seconds: 502 Bad Gateway
and later
[2022-06-23 17:02:31 +0200] [8927/Thread-568] [INFO] Unsupported destination address: 'https://host.domain.tld/username/130E3FED-62C4-4E19-B87E-2001062CB2F5/DD9330C4-9C81-432F-9762-63372C39D0B6.ics'`
`[2022-06-23 17:02:31 +0200] [8927/Thread-568] [DEBUG] Response content:
Remote destination not supported.
Apache Proxy is configured to provide these Headers, quoted from the radicale debug log:
[2022-06-23 17:02:31 +0200] [8927/Thread-568] [DEBUG] Request headers:
{'CONTENT_LENGTH': '0',
'CONTENT_TYPE': 'text/plain',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT': '*/*',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate, br',
'HTTP_ACCEPT_LANGUAGE': 'de-DE,de;q=0.9',
'HTTP_AUTHORIZATION': 'Basic **masked**',
'HTTP_CONNECTION': 'Keep-Alive',
'HTTP_DESTINATION': 'https://host.domain.tld/username/130E3FED-62C4-4E19-B87E-2001062CB2F5/DD9330C4-9C81-432F-9762-63372C39D0B6.ics',
'HTTP_HOST': 'localhost:5232',
'HTTP_USER_AGENT': 'iOS/15.5 (19F77) dataaccessd/1.0',
'HTTP_X_FORWARDED_FOR': 'xxx.xxx.xxx.xxx,
'HTTP_X_FORWARDED_HOST': 'host.domain.tld',
'HTTP_X_FORWARDED_PROTO': 'https',
'HTTP_X_FORWARDED_SERVER': 'host.domain.tld',
'HTTP_X_REAL_IP': '217.225.208.241',
'HTTP_X_REMOTE_USER': 'username',
'PATH_INFO': '/username/35CA95B0-687C-498A-8D84-0A3FDD7E5870/DD9330C4-9C81-432F-9762-63372C39D0B6.ics',
'QUERY_STRING': '',
'REMOTE_ADDR': '127.0.0.1',
'REMOTE_HOST': '',
'REQUEST_METHOD': 'MOVE',
'SCRIPT_NAME': '',
'SERVER_NAME': 'localhost',
'SERVER_PORT': '5232',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SOFTWARE': 'WSGIServer/0.2',
'wsgi.errors': <_io.TextIOWrapper name='<stderr>' mode='w' encoding='utf-8'>,
'wsgi.file_wrapper': <class 'wsgiref.util.FileWrapper'>,
'wsgi.input': <_io.BufferedReader name=7>,
'wsgi.multiprocess': False,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}
Apache virtual host is configured as follows:
<VirtualHost *:443>
ServerName host.domain.tld:443
SSLEngine on
SSLCertificateFile "/etc/ssl/acme/domain.tld/fullchain.pem"
SSLCertificateKeyFile "/etc/ssl/acme/private/domain.tld/privkey.pem"
<Location "/">
AuthType Basic
AuthName "Password Required"
AuthUserFile "/etc/radicale/users"
Require valid-user
ProxyPass http://localhost:5232/ retry=0
ProxyPassReverse http://localhost:5232/
RequestHeader set X-Remote-User expr=%{REMOTE_USER}
RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}
RequestHeader set X-Forwarded-Proto https
</Location>
</VirtualHost>
Yes, we have no other use for a /radicale/ location, but did test it temporary, though.
We also tried different values of the DESTINATION header in order to tell Radicale to use ‘itself' on localhost:5232. Also sanitizing the URL by the proxy /username/…
didn't solve the problem (while presenting other types of errors instead). X_FORWARDED_PROTO was added based on infos given in this thread and values http
and https
were tried.
And it should be mentioned that MOVE-ing an event from one calendar to an other works when clients have access to the Radicale server directly (without proxy. when Radicale is exposed via 443).
Does anyone use a similar setup and has it working?
Is there something missing in our Apache configuration, maybe in the /etc/radicale/config
(ask if relevant)?
Thanks in advance for any idea or assistance.
should be solved by https://github.com/Kozea/Radicale/pull/1271