Closed malud closed 9 months ago
Yes, we should remove that. When using Couper during development on a local machine (in my case MacOS), localhost
is often preferably resolved to its IPv6 IP. That leads to surprising "connection refused" errors when using e.g. http://localhost:8080
instead of http://127.0.0.1:8080
. This happens for example if an SPA server like webpack or vite proxy an API path to Couper. It would be good to be able to use localhost
for that config.
Which kind of configuration would we provide?
this depends on how likely it is that IPv6 causes problems.
For the server {}
part I would say let's add a more generic setting:
settings {
# default: * means both types, all interfaces
# :: just v6
# 0.0.0.0 just v4
# 10.1.0.22 a very specific one, who knows...
bind_address = ["*", "::", "0.0.0.0", "10.1.0.22"]
}
and for the backend part I would use a per backend configuration:
backend {
# so it would not break(?) existing setups
# also a rare case while living in the pod world, use-case: wan origins
use_ipv6 = true
}
How could I add multiple bind IPs on the CLI?
$ couper run --bind ::,0.0.0.0
$ couper run --bind :: --bind 0.0.0
I would suggest comma separated since it aligns best with the environment equivalent.
So backend.use_ipv6
would default to false
?
So
backend.use_ipv6
would default tofalse
?
yes.
would it be useful to have a global use_ipv6
switch, too? to make all backends use ipv6 without cluttering the whole config. That setting could also affect IP binding implicitly.
would it be useful to have a global
use_ipv6
switch, too? to make all backends use ipv6 without cluttering the whole config. That setting could also affect IP binding implicitly.
I would go with a global backend switch which does not affect the bind options.
How would we call that switch? --backend-ipv6
and COUPER_BACKEND_IPV6=true
. I think it is good to have the „backend“ prefix in the switch. But „use“ seems too verbose here. Should we use backend.ipv6 = true
in the config, too?
sounds good. I will update the description.
Update done. So we do not want to enable -backend-ipv6
for all backend and disable this for a single one?
backend {
ipv6 = false
}
Technically we could check for the existing attribute (syntax or bool ptr).
The outgoing backend connection uses/supports already both IPv4 and IPv6.
We need not the backend_ipv6 = true
in the settings and in the backend block...
The outgoing backend connection uses/supports already both IPv4 and IPv6.
Ah, really? So if that is not a change, then I would agree that we don't need to make it configureable now.
Von: Alex Schneider @.***> Gesendet: Donnerstag, 6. April 2023 11:11 An: avenga/couper Cc: Felix Hassert; Comment Betreff: Re: [avenga/couper] remove ipv6 restrictions (Issue #683)
The outgoing backend connection uses/supports already both IPv4 and IPv6.
We need not the backend_ipv6 = true in the settings and in the backend block...
— Reply to this email directly, view it on GitHubhttps://github.com/avenga/couper/issues/683#issuecomment-1498738197, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAD3OQX2LVRSFN6LRZUGKFTW72CD3ANCNFSM6AAAAAAUME2T4Y. You are receiving this because you commented.Message ID: @.***>
Does it use https://en.wikipedia.org/wiki/Happy_Eyeballs for outgoing connections?
We use the resolver/dialer from the standard Go lib. AFAIK, it does a dial race for ipv4/6.
Von: rcanavan @.***> Gesendet: Donnerstag, 6. April 2023 12:51 An: avenga/couper Cc: Felix Hassert; Comment Betreff: Re: [avenga/couper] remove ipv6 restrictions (Issue #683)
Does it use https://en.wikipedia.org/wiki/Happy_Eyeballs for outgoing connections?
— Reply to this email directly, view it on GitHubhttps://github.com/avenga/couper/issues/683#issuecomment-1498872519, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAD3OQXUSI2WQPFV5PT4GBLW72NZPANCNFSM6AAAAAAUME2T4Y. You are receiving this because you commented.Message ID: @.***>
Go is able to handle this but we have restricted the bind and (backend) connect options to ipv4 for simplicity. I guess we could just allow this format and create an option to disable the ipv6 bindings and connections.
Update: So the discussion below leads to the following config proposal:
This applies to the
server {}
block(s) bindings:for the outgoing backend connection configuration: