Purpose of --host-rules?

[Matt Menke]

Does anyone know the purpose of the --host-rules command line argument?  What it currently seems to do is use a set of rules to rewrite the domain name for all requests (i.e., map all requests to www.foo.com:1234 to www.bar.com:321).  It seems like much the same could be accomplished via a proxy, pac script, or --host-resolver-rules (Admittedly, the latter won't rewrite ports).

In general, it just seems like we have way too much needless complexity when setting up the network stack.  Do we really need this as well?  Removing an option is certainly painful to end users that are depending on this, but this all just seems a bit silly.  It also is implemented at the HttpStreamFactoryImpl layer, which seems to mean it can be used to send secure cookies to third party sites (HTTPS only, since it doesn't rewrite scheme), as well as make the omnibox lie about what site you're visiting - admittedly, it's a command line parameter, and if you have that level of control, there are plenty of other things you can do, but overall, seems not great.

[Charles Harrison]

I believe this is used by WebPageTest. Adding pmeenan for more context.

On Wed, May 24, 2017 at 12:37 PM, 'Matt Menke' via net-dev <net...@chromium.org> wrote:

Does anyone know the purpose of the --host-rules command line argument?  What it currently seems to do is use a set of rules to rewrite the domain name for all requests (i.e., map all requests to www.foo.com:1234 to www.bar.com:321).  It seems like much the same could be accomplished via a proxy, pac script, or --host-resolver-rules (Admittedly, the latter won't rewrite ports).

In general, it just seems like we have way too much needless complexity when setting up the network stack.  Do we really need this as well?  Removing an option is certainly painful to end users that are depending on this, but this all just seems a bit silly.  It also is implemented at the HttpStreamFactoryImpl layer, which seems to mean it can be used to send secure cookies to third party sites (HTTPS only, since it doesn't rewrite scheme), as well as make the omnibox lie about what site you're visiting - admittedly, it's a command line parameter, and if you have that level of control, there are plenty of other things you can do, but overall, seems not great.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvq22u4MEWGgekuv3QA6PzbLc6oO7uPNG1SB%3Dyv1-dnwhA%40mail.gmail.com.

[Patrick Meenan]

WPT used to use it before --host-resolver-rules became available but uses --host-resolver-rules now.  Certainly don't hold onto it on my account.

[Matt Menke]

Digging through old bugs, Will Chan described it as a debug-only feature not supported for external use.  I'll plan to remove it after branch, and see how things go.

[Ryan Hamilton]

SGTM. I suspect the history was related to avoiding cert issues. Like you could spin up a test proxy which had a cert for example.com but you wanted it to serve up other.com. So you could host-rules other.com to example.com so that a TLS connection to the proxy would work. But then you would use that connection to request other.com resources.

I suspect we (well chrome devs at least) are long past the need to do that regularly.