I can reproduce this.  Happens for both http://help/ and help/.  Looks like the redirection occurs before it makes it to the network stack, so presumably the omnibox is redirecting 

The omnibox doesn't have the capability to do a redirect like that.  I would assume this is uberproxy, and not a Chrome bug.

Note that no proxy is involved here - the URL is being rewritten before it reaches the network stack.

I can reproduce it on my personal PC, and the reporter is using a gmail account, so is unlikely to be a Google employee.

Experimentally, I can't repro on my personal PC on M58, but after updating to M59, I can.  So pretty clearly a Chrome bug.

[+dbeam, +dpapad]  This looks to have been introduced in https://codereview.chromium.org/2699973002 (Which looks to just have enabled whatever code triggers the bug).

 Issue 735157  has been merged into this issue.

we just need to check url->SchemeIs(content::kChromeUIScheme) in ChromeContentBrowserClient::{anonymous}::HandleWebUI{,Reverse}

Wonder if just grabbing the origin and comparing that against kChromeUIHelpURL and the like would be less regression prone.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/25472e0c801c621e7bd907bbbc57b317efa56fa0

commit 25472e0c801c621e7bd907bbbc57b317efa56fa0
Author: dbeam <dbeam@chromium.org>
Date: Fri Jun 23 19:02:31 2017

MD Settings: fix help/ redirection to only happen on chrome://help

R=tommycli@chromium.org
BUG= 735149 

Review-Url: https://codereview.chromium.org/2949053004
Cr-Commit-Position: refs/heads/master@{#481981}

[modify] https://crrev.com/25472e0c801c621e7bd907bbbc57b317efa56fa0/chrome/browser/chrome_content_browser_client.cc
[modify] https://crrev.com/25472e0c801c621e7bd907bbbc57b317efa56fa0/chrome/browser/chrome_content_browser_client.h
[modify] https://crrev.com/25472e0c801c621e7bd907bbbc57b317efa56fa0/chrome/browser/chrome_content_browser_client_unittest.cc

mmenke@: yeah, that'd be a good improvement, IMO.  I dunno if GetOrigin() wasn't around when most of this code was added or what, but I've slowly been converting various cases over the years away from SchemeIs() + host() -> GetOrigin() == GetOrigin()

Should this be merged to M59?  It may not be the most critical bug, but it does make valid URLs impossible to navigate to.

soooooo, without any merging

<protocol>://help/

all get redirected to a (very-likely) broken URL of

<protocol>://settings/help

until Chrome 61 (which is like forever away).  60 is still a ways away from stable.  59 is also broken and on stable (and affected by this).  merging to 59 makes the most sense, IMO, but is kinda lame cuz merging.

Agreed - since fix is well-contained and well-tested, we should merge to 59.

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This change meets all the requirements and is approved for merge into M60 (build 3112).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae7d311954c7b6b2ea918f381b02e970359e6d6f

commit ae7d311954c7b6b2ea918f381b02e970359e6d6f
Author: dbeam <dbeam@chromium.org>
Date: Mon Jun 26 22:51:34 2017

MD Settings: fix help/ redirection to only happen on chrome://help

R=tommycli@chromium.org
BUG= 735149 

Review-Url: https://codereview.chromium.org/2949053004
Cr-Commit-Position: refs/heads/master@{#481981}
(cherry picked from commit 25472e0c801c621e7bd907bbbc57b317efa56fa0)

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2962603002
Cr-Commit-Position: refs/branch-heads/3112@{#470}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/ae7d311954c7b6b2ea918f381b02e970359e6d6f/chrome/browser/chrome_content_browser_client.cc

We just rolled out M59 today. We are not planning on any further respins. Reading the comments, and that it's marked as P2, it doesn't appear urgent. Let's target this for M60. 

Tested the issue on Windows-10 using chrome latest Beta M60-60.0.3112.50 by following steps mentioned in the original comment. 
Observed that "Http://help/" - page can not be displayed page is displaying in Non corp systems.In corp system its navigating to Moma site.Checked in M57 - 57.0.2987.98 observed the same.Please find the screen shot for reference.

@dbeam: Could you please let me know if i have missed anything and if possible,Please provide the test steps of the issue which would help us to verify the issue further.

Thanks in Advance.

Deleted: 735149(M57).PNG 150 KB

	735149(M57).PNG 150 KB View Download

Deleted: 735149(M60).PNG 165 KB

	735149(M60).PNG 165 KB View Download

rbasuvula:  Are you on a network where http://help/ should resolve?  Regardless, you're getting a DNS error instead of being directed to http://settings/help, so you're not running into the bug.

 Issue 739445  has been merged into this issue.

Curiously, the "chrome" TLD and all domains on it seem to resolve to 127.0.53.53.

Good Afternoon, 

I am currently running 59.0.3071.115 and i am still having the issue. Was this supposed to be resolved in this version. 

According to comment 19, the fix is coming in Chrome 60.

 Issue 746473  has been merged into this issue.