In this article (in Chinese), I discussed installing and using Radicale in termux. However, in most sceneries we are more likely to put radicale behind a web proxy. In this article I take notes on how did I make radicale work with Caddy v2.

If you search “radicale with caddy”, you are more likely to find information about using radicale with Caddy v1. By explicitly searching “radicale with caddy v2” you can fetch meaningful answers as in this post. Though I didn’t find the very post before I worked out the solution myself. T_T

Purpose of writing

To remind myself how the problem evolved, and how did I find the solution.

Forging the Caddyfile for Radicale

First try

Offical documention of Radicale only covers the Nginx and Apache use case. Without too much thinking I wrote the first version in Caddyfile with the Apache example:

reverse_proxy /localtion/ 127.0.0.1:5232 {
        header_up X-Script-Name /location
}

But when I visited /location/ I was welcomed by “Access to the requested resource forbidden.” (A 403 error)

Second thought

What’s up ?

The architecture is some of the chart below:

client <--> server/proxy (Caddy) <--> upstream processor (Radicale) 

The questions are: Who threw the 403 error? Why the error happened?

I first checked radicale through a local web interface:

lynx http://127.0.0.1:5232

It worked. No 403.

And when accessed through Caddy, it raised 403.

Therefore the problem was likely to be with the Caddy side. But by the font I could tell that the response was from Radicale. Was it because Caddy forward something that Radicale disliked? Let me check the log from Radicale by passing the -D flag on command line:

...
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [DEBUG] Script name overwritten by client: '/location'
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [DEBUG] Sanitized script name: '/location'
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [DEBUG] Sanitized path: '/location/'
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [INFO] Successful login: '{user}'
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [INFO] Access to '/location/' denied for '{user}'
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [DEBUG] Response content:
Access to the requested resource forbidden.
[2021-01-26 21:33:57 +0800] [1497/Thread-1] [INFO] GET response status for '/location/' in 0.012 seconds: 403 Forbidden
...

Take note that

[2021-01-26 21:33:57 +0800] [1497/Thread-1] [INFO] Successful login: '{user}'

indicated the authentication was likely to be successful.

And

[2021-01-26 21:33:57 +0800] [1497/Thread-1] [INFO] Access to '/location/' denied for '{user}'

told another story that some wrong path was sent to Radicale. To confirm this, I logged in Radicale from local interface and tried to access http://127.0.0.1/5253/some-random-path. Getting 403 as expected.

At this point it began to be clear that Caddy did not handle the path as what Radicale had expected. And finally I notice there is something written in Radicale’s documention:

The proxy must remove the location from the URL path that is forwarded to Radicale.

Well, I missed that. Let me remove the “location” (see handle_path directive in Caddy v2 doc), then forward the data to Radicale:

handle_path /location/* {
        reverse_proxy 127.0.0.1:5232 {
                header_up X-Script-Name /radicale
        }
}

Well done! This time Radicale was (and is) working behind Caddy!

Afterthought

1. I should have tried different searching key words. So that I didn’t have to spend hours debugging.
2. Reading documents is not an interesting task. Might need read multiple times to avoid the pits and falls.

• linux
• radicale
• caddy