New issue
Advanced search Search tips

Issue 812197 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Uncaught DOMException on XMLHttpRequest.open bad IP URL

Reported by mak...@gmail.com, Feb 14 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3347.0 Safari/537.36

Steps to reproduce the problem:
(new XMLHttpRequest()).open('GET', 'http://1.2.3.456')

What is the expected behavior?
No exception

What went wrong?
Uncaught DOMException: Failed to execute 'open' on 'XMLHttpRequest': Invalid URL

Did this work before? N/A 

Chrome version: 66.0.3347.0  Channel: canary
OS Version: OS X 10.13.3
Flash Version: 

At least Chrome 51.0.2704.90 has no such bug, but Chrome 64.0.3282.137 and the latest Canary for now: 66.0.3347.0 have it.
 
Labels: Needs-Triage-M66
Cc: vamshi.kommuri@chromium.org
Components: -Blink Platform>DevTools
Labels: Triaged-ET M-66 FoundIn-66 Target-66 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 66.0.3347.0 and on the latest stable 64.0.3282.167 using Mac 10.13.1, Windows 10 and Ubuntu 14.04. As the issue is seen from M60(60.0.3072.0) considering it as Non-Regression and marking it as Untriaged.

Comment 3 by ricea@chromium.org, Feb 20 2018

Components: -Platform>DevTools Blink>Network
Status: WontFix (was: Untriaged)
This is not a DevTools issue. It happens even when DevTools is not open.

I think Chrome's behaviour is correct here.

Throwing an exception from open() when a URL fails to parse is correct. See step 7 of https://xhr.spec.whatwg.org/#the-open()-method.

'http://1.2.3.456' should fail to parse according to step 10. of https://url.spec.whatwg.org/#concept-ipv4-parser:

"If the last item in numbers is greater than or equal to 256^(5 − the number of items in numbers), validation error, return failure."

That standard may have specified different behaviour when Chrome 51 was current, or maybe Chrome 51 was just wrong.

Closing as "Won't Fix" (not broken). If anyone has an alternate interpretation of the standard text, they can add a comment.

Sign in to add a comment