Back to Caddyserver

handle_path (Caddyfile directive)

src/docs/markdown/caddyfile/directives/handle_path.md

latest2.0 KB
Original Source
<script> ready(function() { // Add a link to [<path_matcher>] as a special case for this directive. // The matcher text includes <> characters which are parsed as HTML, // so we must use text() to change the link text. $$_('pre.chroma .s').forEach(item => { if (item.innerText.includes('<path_matcher>')) { let text = item.innerText.replace(/</g, '&lt;').replace(/>/g, '&gt;'); item.innerHTML = `<a href="/docs/caddyfile/matchers#path-matchers" style="color: inherit;" title="Matcher token">${text}</a>`; item.classList.remove('s'); item.classList.add('nd'); } }); }); </script>

handle_path

Works the same as the handle directive, but implicitly uses uri strip_prefix to strip the matched path prefix.

Handling a request matching a certain path (while stripping that path from the request URI) is a common enough use case that it has its own directive for convenience.

Syntax

caddy-d
handle_path <path_matcher> {
	<directives...>
}
  • <directives...> is a list of HTTP handler directives or directive blocks, one per line, just like would be used outside of a handle_path block.

Only a single path matcher is accepted, and is required; you cannot use named matchers with handle_path.

Examples

This configuration:

caddy-d
handle_path /prefix/* {
	...
}

šŸ‘† is effectively the same as this šŸ‘‡, but the handle_path form šŸ‘† is slightly more succinct

caddy-d
handle /prefix/* {
	uri strip_prefix /prefix
	...
}

A full Caddyfile example, where handle_path and handle are mutually exclusive; but, be aware of the subfolder problem

caddy
example.com {
	# Serve your API, stripping the /api prefix
	handle_path /api/* {
		reverse_proxy localhost:9000
	}

	# Serve your static site
	handle {
		root /srv
		file_server
	}
}