New issue
Advanced search Search tips

Issue 901644 link

Starred by 1 user

Issue metadata

Status: Available
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Inspect Target Discovery doesn't send Host header

Reported by jack...@jacksondelahunt.com, Nov 4

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
When polling configured network targets, the Host header on calls to `/json` and `/json/version` should be the hostname that was entered into the 'Target discovery settings' window. https://i.imgur.com/2bS0p8Y.png

1. Set up a reverse proxy (e.g. https://hub.docker.com/r/brndnmtthws/nginx-echo-headers/)
2. Set entry in /etc/hosts file for 'inspect-nginx-proxy 127.0.0.1'
3. Add a Target of 'inspect-nginx-proxy:8080' to chrome://inspect

What is the expected behavior?
When polling configured network targets, the Host header on calls to `/json` and `/json/version` should be 'inspect-nginx-proxy'.

What went wrong?
When polling configured network targets, the Host header on calls to `/json` and `/json/version` is '127.0.0.1'.

Did this work before? N/A 

Chrome version: 70.0.3538.77  Channel: stable
OS Version: 18.04
Flash Version: 

For development environments that have multiple node.js processes listening on 9229, it is convenient to use a reverse proxy to route to node.js instances to avoid port conflicts. Without the Host header being set correctly, nginx cannot route incoming requests appropriately.
 
Labels: Needs-Triage-M70
Labels: Triaged-ET TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to setting up reverse proxy in development environments that have multiple node.js processes listening on 9229.
Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!
Owner: dgozman@chromium.org
I see this is in triage awaiting confirmation. As this is a blocker for our deployment, I've created a repro here to move it along: https://github.com/sabrehagen/chrome-devtools-host-header
Labels: -Pri-2 Pri-3
Status: Available (was: Unconfirmed)
This [1] is where we send the /json/version request. From there, it should be possible to debug where does the Host header come from. Perhaps, some code somewhere did resolve inspect-nginx-proxy to 127.0.0.1, and we use the resolved version after that.

[1] https://cs.chromium.org/chromium/src/chrome/browser/devtools/device/devtools_device_discovery.cc?rcl=030ca0ae838b897e824961a4b15e86d3ad2719ce&l=441

Sign in to add a comment