Server error 500 on current-user-principal PROPFIND request

It seems that Radicale does not properly handle the d:current-user-principal request that's part of standard Cal-/CardDAV discovery, and this may be related to the use of uWSGI. I am posting this issue here now, and will augment with further details as I find them:

% echo '<d:propfind xmlns:d="DAV:"><d:prop><d:current-user-principal /></d:prop></d:propfind>' | POST -esSuU -fm PROPFIND -c 'application/xml; charset=utf-8' -C 'madduck@madduck.net:xxxxxxxxxxxx' https://caldav.madduck.net/.well-known/caldav
PROPFIND https://caldav.madduck.net/.well-known/caldav
User-Agent: lwp-request/6.39 libwww-perl/6.39
Content-Length: 86
Content-Type: application/xml; charset=utf-8

401 Unauthorized
Connection: close
Date: Fri, 23 Aug 2019 00:50:18 GMT
Server: Apache/2.4.25 (Debian)
WWW-Authenticate: Basic realm="Radicale"
Content-Length: 466
Content-Type: text/html; charset=iso-8859-1
Client-Date: Fri, 23 Aug 2019 00:50:07 GMT
Client-Peer: 2001:a60:902f::bcae:fdaa:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client-SSL-Cert-Subject: /CN=seamus.madduck.net
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Strict-Transport-Security: max-age=31536000
Title: 401 Unauthorized

PROPFIND https://caldav.madduck.net/.well-known/caldav
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
User-Agent: lwp-request/6.39 libwww-perl/6.39
Content-Length: 86
Content-Type: application/xml; charset=utf-8

500 Internal Server Error
Connection: close
Date: Fri, 23 Aug 2019 00:50:19 GMT
Server: Apache/2.4.25 (Debian)
Content-Length: 619
Content-Type: text/html; charset=iso-8859-1
Client-Date: Fri, 23 Aug 2019 00:50:08 GMT
Client-Peer: 2001:a60:902f::bcae:fdaa:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client-SSL-Cert-Subject: /CN=seamus.madduck.net
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Strict-Transport-Security: max-age=31536000
Title: 500 Internal Server Error

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 webmaster@madduck.net to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.4.25 (Debian) Server at caldav.madduck.net Port 443</address>
</body></html>

Meanwhile, in the Apache logs, I can see:

[Fri Aug 23 02:50:19.561414 2019] [:error] [pid 3727] [client 2404:130:0:1000:a496:f71d:c8d4:b842:12637] uwsgi: read() client block failed !

Notably, if I restart uWSGI, then the next request always seems to be fine, with the answer to the second, authenticated PROPFIND being:

303 See Other
Location: /madduck@madduck.net/calendar.ics/
Client-Date: Fri, 23 Aug 2019 00:52:50 GMT
Client-Peer: 2001:a60:902f::bcae:fdaa:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client-SSL-Cert-Subject: /CN=seamus.madduck.net
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL

However, subsequent requests then get the 500 server error.

Unfortunately, there is nothing in the uWSGI or Radicale (debug) logs that give any further hint as to what might be going on. But it seems that the first uWSGI interaction left the uWSGI handler in an undefined condition, from where it cannot handle the next request.

Bypassing uWSGI and accessing localhost:5232 directly does not produce this problem.

Kozea / Radicale

Server error 500 on current-user-principal PROPFIND request #983