Caddy: rewrite to status 404 does not show custom 404 error page

[peterychuang]

I am using rewrite-to-404 as a way of denying access to a certain files in my site root. While I expect it to show the custom 404 page I defined in the errors block, it instead shows me a plain text "404 Not Found".

Below is my sample Caddyfile:

localhost:5000 {
  root ./public
  gzip

  errors {
    404 404.html
  }

  rewrite /something {
    status 404
  }
}

Not a big deal, but it would be nice if it behaves like other 404 error pages.

[abiosoft]

This is because errors is after rewrite in the middleware chain.

@mholt don't you think errors should be higher up in the chain considering it also has the panic/recover handler.

[mholt]

This is kind of a regression after fixing #914. We can't move errors to be chained in before rewrite, otherwise error pages won't be compressed because gzip is chained in later. @abiosoft and I were chatting in Slack about one possible solution.

We could separate the status code rewriting out of rewrite directive. The rewrite directive would then only rewrite URI, not status code. The new middleware, say, status could then be chained in after errors, allowing the rewritten status code to be served with custom error pages again.

I don't know what Abiola thinks of this yet, but I think I like it. :smile: I don't mind that it breaks the some rewrite directives at this stage (we're pre-1.0), I'm mostly concerned about usability. Will it be confusing? We could clarify the docs to say that rewrite is for rewriting the request URI internally.

[peterychuang]

I would say that having a separate status is actually less confusing than using rewrite for the purpose of setting status code. It could be just me though.

[mholt]

The middleware proposed in #370 is very similar to this status directive we're considering, in that it just iterates rules (even if the 'rule' is just a request path prefix) and writes a status code (and nothing else, I guess) if it finds a matching rule.

Looking at it differently, ext is just a common kind of rewrite that was made for convenience, because it's much easier to use ext than it is to write the rewrite rules yourself.

So perhaps we could also look at forbid and hide as potentially common cases of status. In the future. Maybe not right now. I think status would be a good start, and should be a middleware that's built into Caddy.

[evvvvr]

Would like to take it. Am I right that status directive should have the same syntax/support the same rules as rewrite (except of course status and to entries) i.e. it should look like:
status path status_code
or

status [basepath] {
    regexp pattern
    ext    extensions...
    if     a cond b
    if_op  [and|or]
    status_code
}

?

[mholt]

Well, it could... but what do people really need? Can we start simple and have it just use a base path maybe? status /some_folder 400 or something?

[evvvvr]

Sure, starting with base path only.

[evvvvr]

What is the best place to put this status middleware in? I mean, we could have it exactly after errors, but as I understand, it would be nice to have some other middleware like headers or ipfilter to work before it. Any other examples of middleware chained after errors to run before status?

[mholt]

Good point. How about putting it right after redir? That would allow redirects to take priority over status rewrites, which seems fitting... I think. If not, let's put it right after ratelimit.

[mholt]

This should be fixed now by using the status directive. rewrite no longer allows changing the status code.

[peterychuang]

@mholt @evvvvr @abiosoft Thanks, just built it and it works.