chrome://inspect issues invalid HTTP requests during network target discovery
Reported by
bitcor...@gmail.com,
Nov 9 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Run a program that embeds V8 and supports Inspector. 2. Navigate to chrome://inspect. 3. Click "Configure..." and specify host and port. 4. Click "Done". What is the expected behavior? A debugger link for the application should appear on the chrome://inspect page. What went wrong? No debugger link appears. This is because Chrome issues invalid HTTP GET requests to retrieve network target information. Chrome's requests look like this: GET /json HTTP/1.1 This is invalid because an HTTP/1.1 request must have a Host header. Node.js apparently doesn't care, but other web servers respond with 400 (Bad Request). Chrome should either add a Host header or specify "HTTP/1.0". Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version:
,
Nov 13 2017
@brajkumar Thanks for your response! In step 1 I'm running a custom program that embeds V8 and supports Inspector. It uses an HTTP/WebSocket support library provided by the OS (Windows). When Chrome attempts to retrieve my program's V8 information via "GET /json HTTP/1.1", its request is rejected because it's missing a Host header. My program has no chance to process it. I'm not a Chrome developer, so I don't know what "chrome-TE" is, and I can't post any relevant source code, but you can reproduce the issue with Node.js. If you point chrome://inspect at a running Node.js application and capture Chrome's request using a network traffic analyzer, you'll see that the request specifies HTTP/1.1 but provides no Host header. Node.js's internal Inspector HTTP server doesn't care, but general-purpose HTTP servers are required to reject such requests. "All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field." https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Chrome's behavior in version 62.0.3202.89 is identical.
,
Nov 13 2017
Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 13 2017
eostroukhov@, could you please take a look?
,
Nov 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dea9637f90190fc234d2cbb8b3f768fd0ffd6cfc commit dea9637f90190fc234d2cbb8b3f768fd0ffd6cfc Author: Eugene Ostroukhov <eostroukhov@chromium.org> Date: Wed Nov 22 23:16:02 2017 [DevTools] Send Host header Bug: 783439 Change-Id: Id6a3ed5bed787ef498f175a93b69ea39182055d6 TBR: mmenke (trivial change to devtools server) Reviewed-on: https://chromium-review.googlesource.com/777475 Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Cr-Commit-Position: refs/heads/master@{#518792} [modify] https://crrev.com/dea9637f90190fc234d2cbb8b3f768fd0ffd6cfc/chrome/browser/devtools/device/adb/mock_adb_server.cc [modify] https://crrev.com/dea9637f90190fc234d2cbb8b3f768fd0ffd6cfc/chrome/browser/devtools/device/android_device_manager.cc [modify] https://crrev.com/dea9637f90190fc234d2cbb8b3f768fd0ffd6cfc/net/server/web_socket_encoder.cc
,
Nov 22 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by brajkumar@chromium.org
, Nov 13 2017Labels: Needs-Feedback Needs-Milestone