caddyhttp: Implement status_code handler

[francislavoie]

Closes #3312

Adds a simple status_code handler which simply modifies the HTTP status code of a response.

JSON:

{
    "handler": "status_code",
    "status_code": 404
}

Caddyfile:

status_code [<matcher>] <status>

---

Example usecase:

Caddyfile:

:8884

root .

try_files {path} /404.html
status_code /404.html 404

file_server

Request:

$ curl -v localhost:8884/nope
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8884 (#0)
> GET /nope HTTP/1.1
> Host: localhost:8884
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: Caddy
< Date: Mon, 27 Apr 2020 06:21:34 GMT
< Content-Length: 4
< Content-Type: text/plain; charset=utf-8
<
This is a 404 response page.
* Connection #0 to host localhost left intact

[mohammed90]

Isn't the functionality duplicate of static_response? You can already do:

{
	"handler": "static_response",
	"status_code": "400",
	"close": false
}

and the "close": false is to allow the handler chain to continue.

[francislavoie]

Yes that's true, but there's no way to specify an empty body via Caddyfile, and the syntax wouldn't allow for it either.

[mholt]

I think this approach is not quite right. Instead we need a handler that wraps the ResponseWriter, and has its own WriteHeader method, so that when WriteHeader is called, the configured status code is written instead of the one passed in to WriteHeader.

This functionality might overlap with another pending feature request, I'll look into it more this week.

[francislavoie]

Yeah I see what you mean. I made this PR before actually trying it cause I was overconfident 😅

I needed to return next.ServeHTTP(w, r) instead of return nil which actually does work, but it spits out this warning every time:

2020/04/27 01:35:39 http: superfluous response.WriteHeader call from github.com/caddyserver/caddy/v2/modules/caddyhttp/fileserver.(*FileServer).ServeHTTP (staticfiles.go:239)

[francislavoie]

Turns out NewResponseRecorder is exactly what we need here 👍

It works now, I think this is what you were thinking of.

That said, do you think it would make sense at all to change StaticResponse to wrap the response writer like this and chain if only the status is specified and no body? In other words, keep the response body the same, but just update the status code if that's the only parameter.

Cause then we could do the same but with just the respond directive:

:8884

root .

try_files {path} /404.html
respond /404.html 404

file_server

[mholt]

I think the solution for this problem and #2920 are the same, and I wonder if the right place for it is actually in the existing subroute handler.

The idea is that you capture the response, like you're doing, but then when WriteHeader is called, we invoke a subroute (handler chain) to be evaluated. In theory, this would allow the user to customize the status code that gets written, along with the headers and body if they want to, based on the response headers, which is something that can't currently be done.

[francislavoie]

As noted in #3312 (comment), this isn't really the right approach. Closing.