Hello Pat:
We are using overrideHost extensively in our WPT scripts, and are looking to migrate to the cross-platform agent. The documentation for this agent states that overrideHost is not supported as it “depends on support being added to dev tools”. We have verified through test runs that the command does not work.
Have you heard whether the Chrome or Firefox dev tools have any plans to make the changes required for overrideHost to work?
Thank you, Andrew.
I’ll take a look again and see if anything has changed.
If I remember correctly. the main issue was that neither allowed for changing the host header on outbound network requests from the extension or dev tools protocol (the host header was added at a lower level in the network stack that the extension couldn’t access). That may no longer be the case though since a lot has changed.
There may be hope. I just tested the setHeader command for both Firefox and Chrome and it worked with the Host header so there is some level of it being possible. The main trick is going to be to only change the header for requests bound to the given origin.
For Firefox it should be possible since the headers are modified in an extension that intercepts each request.
For Chrome it is going to be tricky to pull off without impacting performance. The dev tools interface it uses to modify headers only does it globally. Previous experience with using a blocking webRequest handler for Chrome had a LOT of overhead on the actual performance. It is probably going to need to use remote request interception targeted at just the requests for the origin. I’ll have to see what the overhead is but my guess is that it is going to be at least a few milliseconds since it needs to round trip over a websocket (on the same machine).
Just landed the Firefox support. Edge uses similar interfaces but doesn’t look like it allows for modifying the Host header. Taking a look at Chrome now.
I sort of landed initial support for chrome but there are a bunch of caveats:
1 - It currently only works with 67+ (Canary)
2 - Request interception requires turning on the network service (re-architecture of the network stack) and that is still being shaken out so there may be some performance impact.
There’s hope for it in the long term since the network service is the direction Chrome is going in. It may be suitable for testing purposes but you’ll want to look at the results carefully.
btw, it looks like the netlog doesn’t work when the network service is enabled so individual request timings may not be all that accurate (they will be from the renderer perspective).
The top-level metrics and video capture will be accurate but the waterfalls will look a bit off.
Thank you for looking into it so quickly. We will try out overrideHost with Chrome 67.