Issue metadata
Sign in to add a comment
|
HTTP stripped too aggressively for unknown intranet hosts |
||||||||||||||||||
Issue descriptionIf the user is navigated to http://intranethost/path, and intranethost is not a known host, we'll strip the scheme. This will result in displaying "intranethost/path", which would be input that would be parsed as UNKNOWN and thus trigger search-by-default. The effect is that minor edits to the path will result in searches instead of navigations. We should not strip the scheme in this case. This is very similar to the question of when to strip the trailing slash, and in general I don't know what the right fix is. * Does FormatUrlWithAdjustments() need to detect this, as it does the case of a leading "ftp." in the hostname, and avoid stripping? If so, how would it detect this case -- query the in-memory database for this hostname? Is that OK? * Or should AutocompleteInput::FormattedStringWithEquivalentMeaning() re-add the scheme the way it re-adds a trailing slash, if things would parse differently with it? Is this function ever called on input that really isn't a URL, and thus would be incorrectly changed to a URL by doing that? * Or do we need to touch both? Note that if bug 701091 is fixed, I think this issue mostly disappears, because I don't think we can wind up on a host that's not a known intranet host. But maybe if that were in a long-lived tab that sat open past the point where the original navigation was expired?
,
Mar 26 2017
Basically, there are two questions I'd ask: * Can we wind up on an intranethost via some route that bug 701091 didn't cover? If so, this can still occur, and fixing it would be "defense in depth". The long-lived tab is an issue; clearing the browser history while an intranet tab is open is another case; but I'm more worried about unknown unknowns. * Beyond this bug, is there theoretical value in making the scheme-stripping code more robust against "if I strip the scheme, it will change the default behavior"? Rather than hardcode conditions where it's OK to strip schemes/slashes, maybe we really should just classify the input before/after stripping and ensure it's still going to default to the same type of action, to the same destination URL. This might prevent other bugs in the future that aren't intranet-related. Again, this is sort of "unknown unknowns" territory. It's really hard to give tradeoffs here. I guess I'm wondering about the principled value of thoroughness and defensiveness in how scheme-stripping functions.
,
May 11 2017
I can't decide what to do with this now either, but I have a sense this isn't that important. Let's think about it again next year. Hopefully you'll fix bug 701091 for real by then, so the picture for this will be clearer. I'm currently leaning toward WontFix, upon next reassessment, under the premise that the user should never be allowed to be on a page that is an unknown intranet host, and if that happens, that's the bug, not how we display the host / minor edits to the hostname.
,
Jun 1 2017
,
Jun 1 2017
,
Jun 6 2017
Replacing Hotlist=Reassess-2018 label with NextAction=01/09/2018 per omnibox bug triage doc.
,
Jun 6 2017
actually remove the obsolete label
,
Jan 9 2018
The NextAction date has arrived: 2018-01-09
,
Jun 7 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 8 2018
,
Jun 8 2018
,
Jan 8
The NextAction date has arrived: 2019-01-08 |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by mpear...@chromium.org
, Mar 26 2017