1276144 - http://8888 should be treated as an IPv4 address, not a domain.

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[ziyunfei]

> location.href = "http://8888"
Unable to connect: Firefox can’t establish a connection to the server at 8888 // should open http://0.0.34.184

> new URL("http://1073076048").href
"http://1073076048/" // should be "http://63.245.215.80/"

spec: https://url.spec.whatwg.org/#concept-ipv4-parser

Comment 1

[Patrick McManus [:mcmanus]]

make sure to test webcompat

Comment 2

[u408661]

IIRC, this used to be the case (I remember having fun messing with friends in university sending them URLs like this). I also seem to remember a bug a few years back explicitly removing this functionality (not sure what the reasoning was then - likely some combo of security + user expectation, and my bugzilla-fu isn't helping me find it).

Comment 3

[Junior [inactive]]

After some tests,
Chrome stores |new URL("http://2130706433").href| to "http://127.0.0.1"

Safari keeps the original form (i.e., |new URL("http://2130706433").href| returns "http://2130706433/"), but it's able to redirect to http://127.0.0.1 if we navigate by entering address bar. 

I guess modifying in URLParser makes more sense to spec than DNSService.
And use a pref to determine if we need this or not?

Is it a good idea?

Sorry for another quick question, could you elaborate more on _test_webcompat_ in comment 1?
IIRC we can file url-parsing bugs to webcompat.com, but it seems another thing here.

Comment 4

[Anne (:annevk)]

The rationale for the URL Standard is that it's better to canonicalize early, rather than at a lower level of the stack. That way security decisions are more informed.

Junior, as far as testing web compatibility, that means we need to be sure that nothing breaks down if we make this change. Maybe through telemetry, or by shipping it on Nightly and having some way to revert the change easily if it breaks too many things.

Comment 5

[Daniel Stenberg [:bagder]]

Using "http://8888" should use a "Host: 8888" header in the request too, right?

Comment 6

[Anne (:annevk)]

I don't think so, that's way past the point where 8888 is canonicalized.

Comment 7

[Daniel Stenberg [:bagder]]

Then I figure that's another detail for web compat that may differ. curl for example supports "http://8888" since forever (mostly by accident since the resolver functions in most libc do the numerical conversions), but will use the name in the URL as Host: header. It seems match what RFC 7230 says (section 5.5):

   The "Host" header field in a request provides the host and port
   information from the target URI

Do we know of any live sites in the public web that actually assumes a browser to access it with this compact form? I guess the canoncalize-first approach will have a slightly higher chance of working since then it'll become a pure client-side problem.

Does this mean that Firefox should change http://8888 to http://0.0.34.184 in the address bar?

Comment 8

[Junior [inactive]]

(In reply to Daniel Stenberg [:bagder] from comment #7)
> Then I figure that's another detail for web compat that may differ. curl for
> example supports "http://8888" since forever (mostly by accident since the
> resolver functions in most libc do the numerical conversions), but will use
> the name in the URL as Host: header. It seems match what RFC 7230 says
> (section 5.5):
> 
>    The "Host" header field in a request provides the host and port
>    information from the target URI
> 
> Do we know of any live sites in the public web that actually assumes a
> browser to access it with this compact form? I guess the canoncalize-first
> approach will have a slightly higher chance of working since then it'll
> become a pure client-side problem.
I believe lots of malicious sites love those serializing-hosts.

> 
> Does this mean that Firefox should change http://8888 to http://0.0.34.184
> in the address bar?

Bug 1063010 brought this issue for normalizing address bar.
Bug 67730 Comment 53 suggested headers like |Host| should be normalized form in this case.
And Comment 0 was about the error message and |URL.href|

Comment 9

[Junior [inactive]]

Clean the ni since I'm not on the same page in Comment 3.
And thanks for Anne's answer in Comment 4.

Comment 10

[Junior [inactive]]

Landing bug 1288049 indicates this is resolved.

One may doubt that |location.href = "http://8888"| would trigger a silent timeout if 0.0.34.184 is unreachable. That's bug 1163981 and out of scope.