Caddy: Wildcard host bind with proxy cause hostname been cached.

[vibbow]

Caddy version: 0.9 beta 2
Running on Windows Server 2012 R2

Caddy config:

https://*.example.com {
    gzip
    header / -Server
    tls cert.crt cert.key
    header / Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    proxy / https://internal.example.com {
        transparent
        header_downstream -Server ""
    }
}

Expect behavior:
When I access a.example.com, the proxy pass a.example.com as host to backend server
When I access b.example.com, the proxy pass b.example.com as host to backend server.

Real behavior:
The first host I access will be cached in proxy.
For example, after caddy are started, I first access a.example.com, everything works fine.
Then I access b.example.com, the proxy still pass a.example.com as host to backend server.

[mholt]

Thanks for trying the beta! My guess is this is either due to some sort of persistent connection (reusing the http.Client maybe?) or something wrong with how we're setting the headers going upstream. We'll look into it! (I'm away from my computer for a bit.)

[mholt]

I am able to replicate this behavior. I used this Caddyfile to reduce the problem space down to a more minimal set:

:2015
proxy / https://localhost:2016 {
    transparent
}

And I added a fmt.Println to reverseproxy.go so it printed outreq.Host when the request was proxied to the backend. First I loaded http://localhost:2015/abc and saw localhost:2015 being passed upstream, as expected. Then I loaded http://127.0.0.1:2015/abc and still saw localhost:2015 being passed upstream, which was _not_ expected. /cc @evermax

I also tried this in different browsers to see if it was a connection re-use problem between the client and server, but even then, requests from both Chrome and Firefox showed localhost even though Firefox used 127.0.0.1.

[mholt]

Leaving this issue open since @pedronasser and I agree there is a better way to fix this.

[martindale]

I'd like to bump this, hoping there's an easy fix. It's the only remaining issue before we switch to Caddy completely.

[martindale]

@mholt can you point us in the right direction? Perhaps we can write a patch ourselves.

[mholt]

I've been working on this today... seems the replacer is not replacing a {host} value on the second request. (The function that returns r.Host from within the replacer's map is not being called.)

[mholt]

Found the problem. It's right here. It modifies the header rules in-place; it should be changing the copied values instead.

[mholt]

@vibbow @martindale @pedronasser I believe this now fixed. Could you try it out to confirm?

[martindale]

@mholt just installed from master, seems to work now. Thank you so much for fixing this!