26446 2014-07-28 18:30:50 +0000 A URL's port should be an (optional) number, not a string 2015-08-14 14:38:11 +0000 1 1 1 Unclassified WHATWG URL unspecified All All RESOLVED FIXED P2 normal Unsorted 1 simon.sapin annevk d mike rubys zcorpan sideshowbarker+urlspec oldest_to_newest 109400 0 simon.sapin 2014-07-28 18:30:50 +0000 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.) 109471 1 annevk 2014-07-29 09:02:42 +0000 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? 119514 2 d 2015-04-15 06:21:45 +0000 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? 119518 3 annevk 2015-04-15 07:06:20 +0000 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. 119519 4 rubys 2015-04-15 07:20:43 +0000 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 119520 5 annevk 2015-04-15 07:25:42 +0000 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. 119534 6 d 2015-04-15 14:29:35 +0000 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? 119535 7 annevk 2015-04-15 14:46:04 +0000 I'm okay with using this bug for how port should work in general. 119558 8 zcorpan 2015-04-16 07:41:36 +0000 (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 121946 9 simon.sapin 2015-07-10 15:13:48 +0000 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 ) 121982 10 annevk 2015-07-12 07:21:21 +0000 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). 122617 11 annevk 2015-08-14 14:38:11 +0000 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