Allow users to specify that caddy-cache should ONLY cache paths from match_path about caddy-cache

[rickles42]

That makes sense, thanks for the clarification. Maybe the documentation could make this clearer if it were structured along the lines of:

When the cache plugin is enabled, any responses containing headers A, B, or C will be cached, except when <RFC> indicates they should not be. In addition, the presence of match_path instructs the plugin to cache matching responses even without A, B, or C.

[nicolasazrak]

Maybe I should update the documentation, but the idea is to always respect the headers. The "basic usage" (if you specify a path in the config) is just a "hint".

For example: if you add /api, it means to be cached unless a header specifies otherwise. It doesn't override what headers indicate. If /public has a cache-control it will be cached even if it wasn't specified in the config. What it changes when you specify a path in the config is that if /api doesn't has any header, it will be cached.

I hope this clarifies how it works.

[csytan]

I ran into this issue as well. In combo with issue #28, it resulted in the unexpected behavior of serving up empty 304 responses 😮.

I think it's confusing because the label syntax in many other Caddy plugins is activated based on the path. For example: proxy /explicit_path localhost:8080 { ... }.

Confusion results because the label syntax in the cache plugin is opt-out and not based on the path. The naming of the directive match_path doesn't help, because on skimming the docs, it makes it appear to be opt-in and based on the path.

[nicolasazrak]

@csytan The idea was to be able to use it without configure anything and use cache headers. I'm sorry if that's not how it looks. I wanted to offer both ways to enable it: header based rules and config based rules (becase maybe you don't control headers or what a simpler way). What would it be the ideal caddyfile for you having that in mind? (#28 was already solved)

[csytan]

@nicolasazrak I think a path based approach would be easier to understand. For example:

cache /my_website {
    except /my_website/do_not_cache_this_path
}

For backwards compatibility, if no is path specified, then cache every path:

cache {
    ...
}

# above is equivalent to:
cache / {
     ...
}

match_path would be even more confusing at first glance. Perhaps re-naming it to something like cache_path_without_header, force_cache_path, or force_cache would be more obvious. Also deprecating match_path in a future version.

P.S. Thank you for working on this project. Looking forward to trying the fix for #28 👍