caddyhttp: Add support for triggering errors from try_files

[francislavoie]

See #4344, this is a first step towards completing that issue.

Nginx supports a couple pieces of functionality in its implementation of try_files that allow handling the request either as an HTTP error, or by routing to a named location block. http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files

For Caddy, I think it would be quite beneficial to add support to try_files for triggering an error as a fallback case, to short-circuit the request handling early. In many cases, it's not simply the case of "try_files matches, or doesn't".

The one potentially contentious bit here, implementation-wise, is the usage of a placeholder http.matchers.error as a way to carry the error from the matcher logic up to the HTTP handler chain logic. I'm hoping that this would have a minimal performance impact, but I'm not totally certain, haven't benchmarked. It's also I guess kinda cross-cutting concerns. But I don't really see a cleaner way to do this. We can't use r.Context() directly, because that's immutable at this point, so the replacer, being mutable, is the mechanism that would let us do it.

Anyways, an example of how this would look:

:8080 {
	root * /srv
	try_files {path} {path}/index.php =404
	php_fastcgi localhost:9000
	file_server

	handle_errors {
		respond "Error!"
	}
}

Given the files: /srv/foo.js, /srv/index.php, /srv/bar.php

$ curl localhost:8080/foo.js
foo.js contents

$ curl localhost:8080/
index.php executed

$ curl localhost:8080/index.php
index.php executed

$ curl localhost:8080/bar.php
bar.php executed

$ curl localhost:8080/foo.php
Error!

Whereas without this, curl localhost:8080/foo.php would be sent through fastcgi when the file is already known not to exist.

[francislavoie]

While reading through the code, I was reminded that GetVar(ctx, key) and SetVar(ctx, key, val) exist, which seems more appropriate for this than using the replacer. Made the change.

[ttys3]

The first example in the description has a typo,

is it try_files {path} {path}/index.php =404 should be put in a block? (like #4347 (comment)) :

:8080 {
	root * /srv
	php_fastcgi localhost:9000 {
       try_files {path} {path}/index.php =404
    }
	file_server

	handle_errors {
		respond "Error!"
	}
}

[francislavoie]

No, I did that on purpose because this PR doesn't add try_files support to php_fastcgi. That's the job of the other PR.

They're subtly different. Using try_files outside doesn't modify php_fastcgi, but instead just does a try_files redirect before php_fastcgi gets a chance to run. Somewhat similar effect, but has some minor edgecase differences.

[ttys3]

Got it. I like the implementation. This make try_files has more power ( and the php_fastcgi also benefit from it).

try_files, if matched, rewrite it, otherwise trigger an error with code after the = char

Am I correct in this way?

[francislavoie]

Yeah, pretty much. It will rewrite to the first argument that matches a file that exists on disk, or immediately emit an error if it reaches an argument that looks like =[0-9]{3}, essentially

[mholt]

Ok, this actually looks alright. Thanks for the contribution!

[mholt]

LGTM. I still think it's good that matchers don't return errors, especially since returning an error can be an optional utility like in this case, this approach seems better than actual error return value.