reverseproxy: Improve error message when using scheme+placeholder

[francislavoie]

See the discussion here: https://caddy.community/t/proxy-upstream-placeholders/8085

So as it turns out, if you try to use a placeholder as a proxy address, it works fine, unless you also specify a scheme (i.e. the address containing ://), which uses a different code path.

For example with this Caddyfile:

:8080
reverse_proxy http://{host}:8081

The error message when adapting looks like this:

adapt: parsing caddyfile tokens for 'reverse_proxy': Caddyfile:2 - Error during parsing: parsing upstream URL: parse "http://{http.request.host}:8081": invalid character "{" in host name

This doesn't really explain why it doesn't work. This PR adds a condition ahead of the call to url.Parse (which triggers that error) which gives a more useful message:

adapt: parsing caddyfile tokens for 'reverse_proxy': Caddyfile:2 - Error during parsing: for now, placeholders are not allowed when specifying a scheme; instead, omit the scheme and use the transport subdirective if you need tls support

Essentially this just means "omit http:// and it'll work, or omit https:// and use transport { tls } if you need HTTPS".

Also as a note, currently it's impossible to use a SRV address from the Caddyfile and also use placeholders. We could add a srv subdirective that basically skips the parsing checks. Currently, we must parse the scheme to allow SRV because it's set as a different field in the JSON than non-SRV addresses (i.e. dial for non-SRV, and lookup_srv for SRV addresses). With a separate subdirective we could skip the parse step to allow placeholders to pass though... but the use-case for that is so thin that I don't think it's worth the bother for now unless someone specifically shows a valid use-case for it.

[mholt]

Thanks for this. Hmm, given the limited scope of URLs we expect to see here, I wonder if we could and should just write our own simple URL parser to split scheme, host, port (and path if any), which allows placeholders... of course, I guess we'd have to assume that a placeholder would never comprise more than one piece of the URL.

[francislavoie]

Yeah I thought about it but that doesn't seem worth it considering it's completely possible to work around it by just not specifying the scheme.

[mholt]

The whole situation is a bit unfortunate, but as you note, it's easy enough to work around. I don't know a better solution, so I guess this is fine. I just don't want to get too speculative in the error message as to what the user's intention was.