7bac4b15b0
We have made 2 changes in the past that caused an unexpected edge case: 1. when faced with QUIC "no network activity", give up re-attempts and fall-back 2. when a protocol is chosen explicitly, rather than using auto (the default), do not fallback The reasoning for 1. was to fallback quickly in situations where the user may not have chosen QUIC, and simply got it because we auto-chose it (with the TXT DNS record), but the users' environment does not allow egress via UDP. The reasoning for 2. was to avoid falling back if the user explicitly chooses a protocol. E.g., if the user chooses QUIC, she may want to do UDP proxying, so if we fallback to HTTP2 protocol that will be unexpected since it does not support UDP (and same applies for HTTP2 falling back to h2mux and TCP proxying). This PR fixes the edge case that happens when both those changes 1. and 2. are put together: when faced with a QUIC "no network activity", we should only try to fallback if there is a possible fallback. Otherwise, we should exhaust the retries as normal. |
||
|---|---|---|
| .. | ||
| cloudflare_status_page.go | ||
| cloudflare_status_page_test.go | ||
| conn_aware_logger.go | ||
| external_control.go | ||
| metrics.go | ||
| pool.go | ||
| proxy.go | ||
| proxy_posix_test.go | ||
| proxy_test.go | ||
| reconnect.go | ||
| reconnect_test.go | ||
| supervisor.go | ||
| tunnel.go | ||
| tunnel_test.go | ||
| tunnelsforha.go | ||