Hi //net!
@Abhi Patel and I are working on modifying `--proxy-server` to allow specifying proxy chains and/or quic-only proxies.
Both of these pieces of functionality are things we do not want used in "production" - at least not yet, due to:
* security concerns around quic proxies
* not wanting to introduce syntax we will need to support long-term; and
* not committing to a proxy specification meaning "always-use-quic"
However, we do want them to support interoperability testing with various proxies, and to support further testing and development of functionality like HTTP auth and client certs over QUIC proxies, without the bother of getting IP Protection set up. In other words, this is a preliminary step to making QUIC proxy support work outside of IP Protection.
It's unclear if or how we would ever want to expose proxy chain functionality - maybe just to extensions, or just to enterprise policy? Anyway, not a decision we want to make today. And we likely do not want to have a `quic://` proxy scheme, just as we don't have a `spdy://` scheme -- the browser should figure out when to use QUIC, although how to do this is as-yet undecided.
The current implementation (
https://crrev.com/c/5807517) gates the new command-line syntax behind `NDEBUG``, with the intent being that if it only works on devel builds, nobody will be tempted to start using this in their kiosk build or anything like that.
@Matt Menke has suggested using a BUILD_FLAG instead of NDEBUG, for later greppability when removing this.
But maybe hiding this functionality isn't necessary at all? Would a feature be a better choice than a BUILD_FLAG? Or should we just enable this command-line syntax universally?
WDYT?
Dustin