API doesn't work if Caddy's hostname is in format of `http://10.0.0.1:8080` rather than `:8080`

[p0358]

I spent way more time debugging this than I want to admit, but here's a minimal repro:

{
    order cache before rewrite
    cache {
        api {
            souin
        }
    }
}

http://10.0.0.1:8080 {
    respond "Hello World!"
    cache {
        api
    }
}

curl -v 10.0.0.1:8080/souin-api/souin/surrogate_keys
*   Trying 10.0.0.1:8080...
* Connected to 10.0.0.1 (10.0.0.1) port 8080 (#0)
> GET /souin-api/souin/surrogate_keys HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Thu, 25 Jan 2024 00:03:55 GMT
< Content-Length: 0
<
* Connection #0 to host 10.0.0.1 left intact

Now change http://10.0.0.1:8080 to :8080, and it works suddenly:

curl -v 10.0.0.1:8080/souin-api/souin/surrogate_keys
*   Trying 10.0.0.1:8080...
* Connected to 10.0.0.1 (10.0.0.1) port 8080 (#0)
> GET /souin-api/souin/surrogate_keys HTTP/1.1
> Host: localhost
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Caddy
< Date: Thu, 25 Jan 2024 00:04:55 GMT
< Content-Length: 2
<
{}* Connection #0 to host 10.0.0.1 left intact

In a non-minimal scenario it'd just return whatever the app would normally do, such as do reverse proxy as if the endpoint for API didn't exist.

Also it seems this thing is very picky about particularly having cache->api->souin on global config and cache->api on the local one. Generally the configuration seems to be unforgiving...

[darkweak]

Hey @p0358 I'm on it.

[darkweak]

It works using the configuration below:

{
    order cache before rewrite
    cache {
        api {
            souin
        }
    }
}

http://192.168.1.10:8080 {
    respond "Hello World!"
    cache {
        api
    }
}

[darkweak]

curl -v -i 192.168.1.10:8080/souin-api/souin/surrogate_keys
*   Trying 192.168.1.10:8080...
* Connected to 192.168.1.10 (192.168.1.10) port 8080
> GET /souin-api/souin/surrogate_keys HTTP/1.1
> Host: 192.168.1.10:8080
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: application/json
Content-Type: application/json
< Server: Caddy
Server: Caddy
< Date: Sat, 03 Feb 2024 20:13:55 GMT
Date: Sat, 03 Feb 2024 20:13:55 GMT
< Content-Length: 2
Content-Length: 2

< 
* Connection #0 to host 192.168.1.10 left intact
{}

[p0358]

Without any changes to code? I should add that my reproduction was inside of Docker, with official Caddy image, but with caddy file replaced with one built with xcaddy and using --with and this repo. Perhaps this changed something here, because networking in Docker is a tad different, I was using standard port expose, so perhaps from Docker's perspective the IP was different? But the Caddy site itself worked just okay, it was only the API that wouldn't return anything.

Sorry for forgetting to mention it was in Docker straight away...

[darkweak]

I didn't change anything, just used the master latest commit. But in fact even with the latest tagged version it works because it's only related to the path, not to a specific domain (domains are handled by caddy itself) and it's not listening on any specific network interface.
Your behavior is really weird, I would like to get a reproducible repository to investigate on that.