fix: support known tls placeholders replacing even for non tls request

[nikolaevn]

This Caddyfile produce incorrect upstreams headers (placeholders not replaced at all)

http://localhost:1337 {
	reverse_proxy / {
		to http://localhost:1339
		header_up XXX1 {http.request.tls.client.certificate_der_base64}
		header_up XXX2 {http.request.tls.client.san.uris.0}
	}
}

Without this PR upstream gets following:

GET / HTTP/1.1
Host: localhost:1337
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: localhost:1337
X-Forwarded-Proto: http
Xxx1: {http.request.tls.client.certificate_der_base64}
Xxx2: {http.request.tls.client.san.uris.0}

with PR:

GET / HTTP/1.1
Host: localhost:1337
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: localhost:1337
X-Forwarded-Proto: http
Xxx1: 
Xxx2: 

[CLAassistant]

All committers have signed the CLA.

[mholt]

Thanks for the PR!

This looks good, but before merging I just want to double check if this is the way we want it to work.

We could alternatively simply change repl.ReplaceKnown() (in headers.go) to repl.ReplaceAll() -- assuming that header fields don't otherwise have {...} in them. That's why I used ReplaceKnown up to now.

So, this is probably the safest way to go but it is a bit repetitive (which is fine, as I don't know another way to do it). Any thoughts? (Don't change your patch though.)

[francislavoie]

I think that changes in #5275 will affect what needs to be done here, once that one is completed.

[mholt]

Another idea I just had is, if the connection isn't TLS, the replacer can return nil, true for the TLS-related placeholders, indicating that the placeholder keys are recognized, but that they have no value.

I actually think this would be a more correct, simpler approach... and given the age of this PR, I might close this one for now, but we can either reopen it if it gets updated, or review a new PR.