Please remove this

I'm not convinced this is the right place for this directive in the middleware chain. This list is the order in which middlewares are executed: both during set up and during actual request-time (if they inject handlers).

First things first: to keep track of which directives are third-party plugins, please add a comment to this line with the path to your cache package (as you can see on many of the other lines, sorry if it wasn't explicit in the wiki). // github.com/nicolasazrak/caddy-cache

Next, I think we should move it lower in the list... at least probably not "on its own" like this. I wouldn't know for sure where it belongs, but typically you'll want handlers to go as late in the middleware chain as is possible while having it still work properly. If your handler terminates the chain by serving the response, then the request will never see the rewrite handler, which might break things if people are using it to rewrite URIs. It also comes before the errors directive. Most middleware will want to come after that so that errors returned by your handler can be properly handled. But then again, I don't know for sure in the case of a cache middleware... if you cache the error pages too, then maybe it doesn't matter? (Maybe cache belongs a little lower at least, like where the handler directives are.)

Anyway, I hope that makes sense. If you're unsure, try testing with a few of the directives to see if your cache behaves the way you expect. If not, make sure to move it lower in the chain.

After looking the order for a while I cannot find the correct place. I think it should be after log and errors but it also should be before gzip and maybe even before ratelimit, but errors is after gzip.

Although being after gzip (or minify) will work, caching gzipped responses can save a lot of cpu. As cache goes lower in the list, more duplicated tasks will be made, defeating the cache purpose which is avoid them. Maybe moving errors after log and putting cache after (log -> error -> cache) would solve the issue.

Being before rewrite should not be a problem because given an request url the rewrite should be the same and caching still applies.

If being lower in the list will not serve its purpose well, then it's okay to keep it higher. I can definitely understand wanting to keep it above gzip so you can cache compressed responses where clients accept the same encoding.

As long as URL rewrites don't ever have a 1:many mapping, putting cache before rewrite should be fine.

Just don't put it in its own space. ;) The whitespace (empty lines) seem to signal that cache is on its own and I think it's best if it fits in as close as it can with existing groups.

(To clarify/summarize, in case I wasn't clear: go ahead and leave it where it is, if you think this is best, just put it in the last big group with the others, rather than off by its own.)

I will leave it after log (without whitespace). Is it ok moving errors after log? So cache errors can be handled. The only problem I see is that error pages will not be compressed, but that should not be a big problem.

About rewrite having 1:many mapping, in that case rewrite should add Vary header to inform that depending on some header the response could change.

No, don't reorder any of the other directives. Just leave cache where it best belongs, which after your investigation, is apparently in this place. Just remove the whitespace so it fits in the group. Thanks!