This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the spec defines an URL’s port as string of digits of arbitrary length. However, implementations seem to be storing it as a number with limited range, internally. Test case: data:text/html,<a href="http://example.com:65535"></a><script>document.write(document.querySelector('a').port)</script> This works everywhere as expected and displays "65535". When changing 65535 to higher numbers: For 65536 (2^16) or above, Chromium displays "0". For 65536 (2^16) or above, IE displays the empty string. For 2147483648 (2^31) or above, Firefox displays the empty string. I suggest changing the URL parser to interpret the digits of the port as a decimal number, return failure if it’s 65536 or more (i.e., would overflow a 16 bit unsigned integer), and change "A URL's port" in the model to be either null or a 16 bit number. Note that port numbers are 16 bit (from 0 to 65535) in both TCP and UDP (though only TCP is really relevant here.)
This seemed like a place where we could follow the RFCs going forward. Did you check with Necko peers whether they want to pursue convergence with Chrome and IE here?
io.js is looking for guidance on what their port setter should do, and perhaps separately what their port parser should do. See https://github.com/iojs/io.js/pull/933#issuecomment-93215122 It sounds like the plan is empty string? Or is it "0"? Should port return a JS number or a JS string?
URL.prototype.port's get will return a string and its set will stringify. This bug is about the private port slot which we may want to change from string to integer to deal better with the 2^16 limit.
Current test results show that the case being discussed on the IO.JS issue is one where four current browsers come up with four different results: https://url.spec.whatwg.org/interop/test-results/c6c0953a53?select=current Browser vendor review of the spec would be helpful. See also: https://lists.w3.org/Archives/Public/public-url/2015Apr/0000.html
Not sure why we need to discuss this on a (new?) mailing list. That test is not testing API. And this bug is not about the API.
Thanks for taking the time to help Sam. (Although agreed that a new mailing list not a great idea here.) As Anne points out, there's a difference between parsing (what that test tests) and the setter. For example in Chrome 999999 parses as "0", whereas when using the setter it simply ignores any values above 65535. Anne, would you prefer the question of the setter behavior in a separate bug, since you say this one is not about the API? Or should we assume the setter always has the same behavior as the parser, and continue using this bug for the former?
I'm okay with using this bug for how port should work in general.
(In reply to Domenic Denicola from comment #6) > For example in Chrome 999999 parses as "0", Yes. > whereas > when using the setter it simply ignores any values above 65535. No, it uses mod 2^16 AFAICT http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3500
Valentin Gosu from the Necko team is in favor of restricting port numbers to the range of unsigned 16 bit integers: https://github.com/servo/rust-url/issues/115#issuecomment-120059106 (This will probably happen as part of switching Gecko to rust-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1151899 )
He brings up an interesting point. That if we change the type we need to consider the default port case. So I guess it'd have to be (null or 16-bit integer).
Thank you for the report. I decided against Chrome and made the parser and the setter behave identically for overflow values. I hope that is compatible. https://github.com/whatwg/url/commit/c3a454c073d6bf9f24d8ee2b5c3e6e006b943777