Feature request: customization of cache key

[p0358]

Currently it's pretty much just hardcoded to method+scheme+host+key+query+body+headerValues, with the ability to drop some of these fields, but not to add new ones. Only the option to specify request headers gives us some flexibility with which I was allowed to do that:

    map {header.Cookie} {site_language} {
        ~.*language_id=2.* "en"
        default "pl"
    }
    request_header X-Site-Language {site_language}
    header X-Site-Language {site_language}

also gotta do this in main config for that:

{
    order cache before rewrite
    order request_header before cache
}

Now that is pretty hacky and cumbersome. Wouldn't it be nice if we could specify a custom pattern that could be added or even replace the key with something custom?

Such as:

# pseudocode
cache {
    key {
        custom KEY-{http.request.uri.query}-{site_language}
    }
}

[p0358]

On an unrelated note, I seem to witness some worrisome behavior with cache output being randomly broken

curl -v http://localhost:4443/esi
*   Trying 127.0.0.1:4443...
* Connected to localhost (127.0.0.1) port 4443 (#0)
> GET /esi HTTP/1.1
> Host: localhost:4443
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Age: 27
< Cache-Control: public
< Cache-Status: Souin; hit; ttl=973; key=GET-http-localhost:4443-/esi
< Content-Length: 97
< Content-Type: text/html
< Date: Thu, 25 Jan 2024 00:44:39 GMT
< Server: Caddy
<
<h1>ESI INCLUDE</h1>* transfer closed with 77 bytes remaining to read
* Closing connection 0
curl: (18) transfer closed with 77 bytes remaining to read

This is with the example Caddyfile from this repo. Had similar behavior with browser on another OS (this one is ran on Windows), but managed to solve it by disabling gzip seemingly (or by explicitly providing Accept-Encoding as one of headers to be part of the cache key. But the weird thing is:

1. curl doesn't use any content encoding by default
2. browsers do seem to always send the same "Accept-Encoding" value when requesting pages
   ...so something doesn't add up here either

[p0358]

Look at the mismatch of Content-Length header when it's cache miss or hit

curl -v http://localhost:4443/esi
*   Trying 127.0.0.1:4443...
* Connected to localhost (127.0.0.1) port 4443 (#0)
> GET /esi HTTP/1.1
> Host: localhost:4443
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: public
< Cache-Status: Souin; fwd=uri-miss; stored; key=GET-http-localhost:4443-/esi
< Content-Type: text/plain; charset=utf-8
< Server: Caddy
< Date: Thu, 25 Jan 2024 00:49:16 GMT
< Content-Length: 20
<
<h1>ESI INCLUDE</h1>* Connection #0 to host localhost left intact

curl -v http://localhost:4443/esi
*   Trying 127.0.0.1:4443...
* Connected to localhost (127.0.0.1) port 4443 (#0)
> GET /esi HTTP/1.1
> Host: localhost:4443
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Age: 3
< Cache-Control: public
< Cache-Status: Souin; hit; ttl=997; key=GET-http-localhost:4443-/esi
< Content-Length: 97
< Content-Type: text/plain; charset=utf-8
< Date: Thu, 25 Jan 2024 00:49:16 GMT
< Server: Caddy
<
<h1>ESI INCLUDE</h1>* transfer closed with 77 bytes remaining to read
* Closing connection 0
curl: (18) transfer closed with 77 bytes remaining to read

The above is on Windows with caddy downloaded freshly from their site with Souin selected as the only addon.

[darkweak]

Hello @p0358 does your PR #445 fix that?

[p0358]

@darkweak I think that'd be it yeah, at very first I didn't realize it was related to ESI

[darkweak]

I have to check why it returns a bad Content-Length in the Caddy test suite

[darkweak]

@p0358 your PR is ready, thank you for your contribution! 🚀