intercept

A generalized abstraction of the response interception feature from the reverse_proxy directive. This may be used with any handler that produces responses, including those from plugins like FrankenPHP's php_server.

This directive allows you to match responses, and the first matching handle_response route or replace_status will be invoked. When invoked, the original response body is held back, giving the opportunity to that route to write a different response body, with a new status code or with any necessary response header manipulations. If the route does not write a new response body, then original response body is written instead.

Syntax

intercept [<matcher>] {
	@name {
		status <code...>
		header <field> [<value>]
	}

	replace_status [<matcher>] <code>

	handle_response [<matcher>] {
		<directives...>
	}
}

• @name is the name of a response matcher. As long as each response matcher has a unique name, multiple matchers can be defined. A response can be matched on the status code and presence or value of a response header.

• replace_status simply changes the status code of response when matched by the given matcher.

• handle_response defines the route to execute when matched by the given matcher (or, if a matcher is omitted, all responses). The first matching block will be applied. Inside a handle_response block, any other directives can be used.

Within handle_response routes, the following placeholders are available to pull information from the original response:

• {resp.status_code} The status code of the original response.

• {resp.header.*} The headers from the original response.

Examples

When using FrankenPHP's php_server, you can use intercept to implement X-Accel-Redirect support, serving static files as requested by the PHP app:

localhost {
	root * /srv

	intercept {
		@accel header X-Accel-Redirect *
		handle_response @accel {
			root * /path/to/private/files
			rewrite {resp.header.X-Accel-Redirect}
			method GET
			file_server
		}
	}

	php_server
}