New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

url: refactor truncating long hostname #9292

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@jun-oka
Contributor

jun-oka commented Oct 26, 2016

Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

lib url
test url

Description of change

I deleted and refactored the line around 417 in url.js which was truncating hostname if hostname length after . is more than 63. Thus url parse behavior for hostname should be same as browser's behavior. Now it doesn’t truncate hostname.

@cjihrig

LGTM I suppose.

@mscdex mscdex added the url label Oct 26, 2016

@Trott

Trott requested changes Oct 26, 2016 edited

The moving-part-of-the-hostname-to-the-path bit is really surprising and, I would argue, buggy behavior. Is that documented anywhere? If not, I wonder if the correct thing to do is a (hopefully semver-patch) change that treats such URLs as invalid. (A hostname longer than 63 chars is invalid per RFC 1035.)

EDIT: It doesn't appear to be documented anywhere.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Oct 26, 2016

Member

/cc @nodejs/http-parser I guess, although I suppose this isn't http-specific...

Member

Trott commented Oct 26, 2016

/cc @nodejs/http-parser I guess, although I suppose this isn't http-specific...

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Oct 26, 2016

Contributor

@Trott OK. I agree. I'll look into the document again.
The only way I could pass this URL on test was this way, so I thought it was true.
However, according to your opinion, it seems buggy.

Contributor

jun-oka commented Oct 26, 2016

@Trott OK. I agree. I'll look into the document again.
The only way I could pass this URL on test was this way, so I thought it was true.
However, according to your opinion, it seems buggy.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Oct 26, 2016

Member

Looks like this behavior was introduced (or at least refactored?) in db91281 by @mscdex. I'm not sure if it was unintentional and the intended behavior was something else, or if this is totally intended behavior on the theory that "garbage input results in garbage output". So maybe @mscdex can let us know?

Member

Trott commented Oct 26, 2016

Looks like this behavior was introduced (or at least refactored?) in db91281 by @mscdex. I'm not sure if it was unintentional and the intended behavior was something else, or if this is totally intended behavior on the theory that "garbage input results in garbage output". So maybe @mscdex can let us know?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell
Member

jasnell commented Oct 28, 2016

ping @mscdex

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Oct 28, 2016

Contributor

I honestly don't remember, that was awhile ago. All I could go by is whatever tests we had at the time.

Contributor

mscdex commented Oct 28, 2016

I honestly don't remember, that was awhile ago. All I could go by is whatever tests we had at the time.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Oct 28, 2016

Member

Looking at what new URL(url) does in the browser, it does not truncate the hostname component. I would say we should follow suit: Don't try to validate the hostname length.

I would say the path forward is:

  • rewrite the expected test result to preserve the hostname
  • update url.js to not truncate long hostnames
  • update the subsystem in the PR name and the commit message to be url
  • Get some input from @nodejs/lts on the semver implications of this. I think it's a bug fix, personally, but if anyone wants to argue that it should be treated as semver-major out of an abundance of caution, I'm OK with that.

What do others think?

Member

Trott commented Oct 28, 2016

Looking at what new URL(url) does in the browser, it does not truncate the hostname component. I would say we should follow suit: Don't try to validate the hostname length.

I would say the path forward is:

  • rewrite the expected test result to preserve the hostname
  • update url.js to not truncate long hostnames
  • update the subsystem in the PR name and the commit message to be url
  • Get some input from @nodejs/lts on the semver implications of this. I think it's a bug fix, personally, but if anyone wants to argue that it should be treated as semver-major out of an abundance of caution, I'm OK with that.

What do others think?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Oct 28, 2016

Member

I should add that, to me at least, the real objectionable thing here is not the truncation but the moving of the remainder of the hostname into the path. That just makes no sense to me. I cannot think of a situation where that is helpful. And I can think of situations where that can introduce bugs, for sure.

Member

Trott commented Oct 28, 2016

I should add that, to me at least, the real objectionable thing here is not the truncation but the moving of the remainder of the hostname into the path. That just makes no sense to me. I cannot think of a situation where that is helpful. And I can think of situations where that can introduce bugs, for sure.

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Nov 4, 2016

Contributor

@Trott Thanks.
I will do this part.

  • rewrite the expected test result to preserve the hostname
  • update url.js to not truncate long hostnames
  • update the subsystem in the PR name and the commit message to be url
Contributor

jun-oka commented Nov 4, 2016

@Trott Thanks.
I will do this part.

  • rewrite the expected test result to preserve the hostname
  • update url.js to not truncate long hostnames
  • update the subsystem in the PR name and the commit message to be url
@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Nov 10, 2016

Member

re: #9521 (comment), I think truncation is bizarre.

I don't believe that the URL RFCs say that host names have to be _DNS_ host names, there are lots of ways of resolving names, so I think truncation is a bug.

Here's an example:

% tail /etc/hosts

127.0.0.1 ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com
% ping -c1 ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com
PING ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.065 ms

host names clearly are not the same as DNS names, they can be longer than DNS allows and still be resolveable.

Member

sam-github commented Nov 10, 2016

re: #9521 (comment), I think truncation is bizarre.

I don't believe that the URL RFCs say that host names have to be _DNS_ host names, there are lots of ways of resolving names, so I think truncation is a bug.

Here's an example:

% tail /etc/hosts

127.0.0.1 ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com
% ping -c1 ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com
PING ThisIsAnAbsurdlyLongHostNameButSurelyNoneOfThisShouldEndUpAsPartOfThePathBecauseWhoCouldPossiblyWantThatAMIRITE.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.065 ms

host names clearly are not the same as DNS names, they can be longer than DNS allows and still be resolveable.

@jun-oka jun-oka changed the title from test: expand test coverage for url.js to url: stop to truncate long hostname into path Dec 1, 2016

@jun-oka jun-oka changed the title from url: stop to truncate long hostname into path to url: stop to truncate long hostname Dec 1, 2016

@jun-oka jun-oka changed the title from url: stop to truncate long hostname to url: stop truncating long hostname Dec 1, 2016

@jun-oka jun-oka changed the title from url: stop truncating long hostname to url: refactor truncating long hostname Dec 1, 2016

@Trott

Trott approved these changes Dec 1, 2016

LGTM if new CI is

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 1, 2016

Member

@cjihrig @jasnell This is a bit different (and, in my opinion, better) than what was originally submitted. Can you re-check the code to make sure it is still good by you?

Member

Trott commented Dec 1, 2016

@cjihrig @jasnell This is a bit different (and, in my opinion, better) than what was originally submitted. Can you re-check the code to make sure it is still good by you?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott
Member

Trott commented Dec 1, 2016

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Dec 7, 2016

Contributor

@cjihrig @jasnell @sam-github It would be nice if you can check it!

Contributor

jun-oka commented Dec 7, 2016

@cjihrig @jasnell @sam-github It would be nice if you can check it!

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Dec 7, 2016

Member

I'm not familiar with the code, it would make more sense for @jasnell (who just wrote a URL decoder) or @mscdex (who might have implemented the truncation) looked at it.

Member

sam-github commented Dec 7, 2016

I'm not familiar with the code, it would make more sense for @jasnell (who just wrote a URL decoder) or @mscdex (who might have implemented the truncation) looked at it.

@mscdex mscdex added the semver-major label Dec 7, 2016

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Dec 7, 2016

Contributor

IMHO this is changing behavior, especially since it was already limiting to 63 (via a regex) before the rewrite, so I would vote for semver-major.

I think conformance to browsers at this point is probably better handled in @jasnell's separate URL implementation.

Contributor

mscdex commented Dec 7, 2016

IMHO this is changing behavior, especially since it was already limiting to 63 (via a regex) before the rewrite, so I would vote for semver-major.

I think conformance to browsers at this point is probably better handled in @jasnell's separate URL implementation.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Dec 7, 2016

Member

I agree about browser conformance, but don't see this as browser conformance, but as simply a bug. I can't see a time when anyone would want their hostnames silently truncated. I'm OK with semver-major if we are really nervous, though.

Member

sam-github commented Dec 7, 2016

I agree about browser conformance, but don't see this as browser conformance, but as simply a bug. I can't see a time when anyone would want their hostnames silently truncated. I'm OK with semver-major if we are really nervous, though.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 7, 2016

Member

I think this is a bug fix too. There is no conceivable scenario where the current behavior is desirable, in particular the part that converts part of the host name into the start of the path. That seems buggy at best and dangerous at worst.

That said, this isn't the issue I'd pick to have an extended discussion on it, so if anyone wants it as semver-major, then OK, semver-major it is and let's move on.

Member

Trott commented Dec 7, 2016

I think this is a bug fix too. There is no conceivable scenario where the current behavior is desirable, in particular the part that converts part of the host name into the start of the path. That seems buggy at best and dangerous at worst.

That said, this isn't the issue I'd pick to have an extended discussion on it, so if anyone wants it as semver-major, then OK, semver-major it is and let's move on.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Dec 8, 2016

Member

host names clearly are not the same as DNS names, they can be longer than DNS allows and still be resolveable

Yes, but only if the resolver supports it. Your example probably wouldn't work if it was > 254 characters.

Member

bnoordhuis commented Dec 8, 2016

host names clearly are not the same as DNS names, they can be longer than DNS allows and still be resolveable

Yes, but only if the resolver supports it. Your example probably wouldn't work if it was > 254 characters.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Dec 8, 2016

Member

My resolver worked fine with a 333 character + '.com' host in /etc/hosts, but I don't think that matters. Yes, resolvers might impose some limitations, but the url lib doesn't know those limitations, and truncating the host portion of a URL and sticking the tail of it into the path value doesn't seem a reasonable response to host names over some length, no matter what the length is.

Do you think it is, @bnoordhuis?

Member

sam-github commented Dec 8, 2016

My resolver worked fine with a 333 character + '.com' host in /etc/hosts, but I don't think that matters. Yes, resolvers might impose some limitations, but the url lib doesn't know those limitations, and truncating the host portion of a URL and sticking the tail of it into the path value doesn't seem a reasonable response to host names over some length, no matter what the length is.

Do you think it is, @bnoordhuis?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Dec 8, 2016

Member

I don't, it was an off-the-cuff remark. Surprised such long hostnames work for you locally.

Member

bnoordhuis commented Dec 8, 2016

I don't, it was an off-the-cuff remark. Surprised such long hostnames work for you locally.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Dec 8, 2016

Member

I'm mildly surprised, too. I doubt it would work over NIS or YP, but I've no intention of setting those up to see.

Member

sam-github commented Dec 8, 2016

I'm mildly surprised, too. I doubt it would work over NIS or YP, but I've no intention of setting those up to see.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 8, 2016

Member

@mscdex OK to land this as a bugfix? Or are you still of the opinion that this is semver major? I'll go with whichever you think is right.

Member

Trott commented Dec 8, 2016

@mscdex OK to land this as a bugfix? Or are you still of the opinion that this is semver major? I'll go with whichever you think is right.

Show outdated Hide outdated lib/url.js
continue;
}
for (var i = 0; i <= hostname.length; ++i) {
const code = hostname.charCodeAt(i);

This comment has been minimized.

@mscdex

mscdex Dec 8, 2016

Contributor

The conditional that previously preceded this needs to be kept, otherwise there will be a deopt (at least in node v6.x) when trying to access an index that is out of bounds (when i === hostname.length).

@mscdex

mscdex Dec 8, 2016

Contributor

The conditional that previously preceded this needs to be kept, otherwise there will be a deopt (at least in node v6.x) when trying to access an index that is out of bounds (when i === hostname.length).

This comment has been minimized.

@jun-oka

jun-oka Dec 9, 2016

Contributor

@mscdex Would you give me a little bit more detail about which part you are talking by "The conditional that previously preceded this needs to be kept" ?

@jun-oka

jun-oka Dec 9, 2016

Contributor

@mscdex Would you give me a little bit more detail about which part you are talking by "The conditional that previously preceded this needs to be kept" ?

This comment has been minimized.

@mscdex

mscdex Dec 9, 2016

Contributor

Previously there was a conditional before calling hostname.charCodeAt(i):

var code;
if (i < hostname.length)
  code = hostname.charCodeAt(i);
@mscdex

mscdex Dec 9, 2016

Contributor

Previously there was a conditional before calling hostname.charCodeAt(i):

var code;
if (i < hostname.length)
  code = hostname.charCodeAt(i);

This comment has been minimized.

@mscdex

mscdex Dec 23, 2016

Contributor

This still needs to be changed as well. Also, the for conditional also needs to continue to be <= hostname.length to avoid duplicating the code inside the loop, immediately after the loop.

@mscdex

mscdex Dec 23, 2016

Contributor

This still needs to be changed as well. Also, the for conditional also needs to continue to be <= hostname.length to avoid duplicating the code inside the loop, immediately after the loop.

This comment has been minimized.

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex OK. Thank you so much for your advice. How about like this?
https://gist.github.com/jun-oka/79b87bfc465ede72780ab0f3164df90c

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex OK. Thank you so much for your advice. How about like this?
https://gist.github.com/jun-oka/79b87bfc465ede72780ab0f3164df90c

This comment has been minimized.

@mscdex

mscdex Dec 24, 2016

Contributor

Actually, scratch that. I guess it's not needed for the new behavior.

@mscdex

mscdex Dec 24, 2016

Contributor

Actually, scratch that. I guess it's not needed for the new behavior.

This comment has been minimized.

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex So can we keep my latest committed code for this part?

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex So can we keep my latest committed code for this part?

This comment has been minimized.

@mscdex

mscdex Dec 24, 2016

Contributor

Yes.

@mscdex

mscdex Dec 24, 2016

Contributor

Yes.

This comment has been minimized.

@jun-oka

jun-oka Dec 24, 2016

Contributor

I got it!

@jun-oka

jun-oka Dec 24, 2016

Contributor

I got it!

Show outdated Hide outdated lib/url.js
}
for (var i = 0; i <= hostname.length; ++i) {
const code = hostname.charCodeAt(i);
const isVc = code === 46/*.*/ ||

This comment has been minimized.

@mscdex

mscdex Dec 8, 2016

Contributor

A better variable name could be used here, like isValid or something a little more clearer/verbose.

@mscdex

mscdex Dec 8, 2016

Contributor

A better variable name could be used here, like isValid or something a little more clearer/verbose.

This comment has been minimized.

@jun-oka

jun-oka Dec 9, 2016

Contributor

OK. I agree!

@jun-oka

jun-oka Dec 9, 2016

Contributor

OK. I agree!

This comment has been minimized.

@mscdex

mscdex Dec 23, 2016

Contributor

This still needs to be changed.

@mscdex

mscdex Dec 23, 2016

Contributor

This still needs to be changed.

This comment has been minimized.

@jun-oka

jun-oka Dec 24, 2016

Contributor

Yes. I overlooked.

@jun-oka

jun-oka Dec 24, 2016

Contributor

Yes. I overlooked.

Show outdated Hide outdated lib/url.js
const code = hostname.charCodeAt(i);
const isVc = code === 46/*.*/ ||
code >= 48/*0*/ && code <= 57/*9*/ ||
code >= 97/*a*/ && code <= 122/*\z*/ ||

This comment has been minimized.

@mscdex

mscdex Dec 8, 2016

Contributor

There is a backslash before z here that needs to be removed.

@mscdex

mscdex Dec 8, 2016

Contributor

There is a backslash before z here that needs to be removed.

This comment has been minimized.

@jun-oka

jun-oka Dec 9, 2016

Contributor

OK. Thank you for finding.

@jun-oka

jun-oka Dec 9, 2016

Contributor

OK. Thank you for finding.

Show outdated Hide outdated lib/url.js
for (var i = 0; i <= hostname.length; ++i) {
const code = hostname.charCodeAt(i);
const isVc = code === 46/*.*/ ||
code >= 48/*0*/ && code <= 57/*9*/ ||

This comment has been minimized.

@mscdex

mscdex Dec 8, 2016

Contributor

Please keep the parens around the groups of checks, IMHO it makes it easier to reason about.

@mscdex

mscdex Dec 8, 2016

Contributor

Please keep the parens around the groups of checks, IMHO it makes it easier to reason about.

This comment has been minimized.

@jun-oka

jun-oka Dec 9, 2016

Contributor

Yes. I think so too.

@jun-oka

jun-oka Dec 9, 2016

Contributor

Yes. I think so too.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Dec 8, 2016

Contributor

@Trott I'm just being more cautious is all, especially since this behavior has existed for a long time (even before my rewrite). If everyone else feels differently, then go ahead and remove the semver-major label.

Contributor

mscdex commented Dec 8, 2016

@Trott I'm just being more cautious is all, especially since this behavior has existed for a long time (even before my rewrite). If everyone else feels differently, then go ahead and remove the semver-major label.

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Dec 9, 2016

Contributor

@mscdex
Thank you for those reviewing.
I will look into them.

Contributor

jun-oka commented Dec 9, 2016

@mscdex
Thank you for those reviewing.
I will look into them.

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Dec 23, 2016

Contributor

@mscdex @Trott
I have just updated!

Contributor

jun-oka commented Dec 23, 2016

@mscdex @Trott
I have just updated!

@Trott

This comment has been minimized.

Show comment
Hide comment
@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Dec 24, 2016

Contributor

There's a couple of changes that still need to be made, namely the for loop iteration condition and the isVc variable naming.

Contributor

mscdex commented Dec 24, 2016

There's a couple of changes that still need to be made, namely the for loop iteration condition and the isVc variable naming.

@jun-oka jun-oka closed this Dec 24, 2016

@jun-oka jun-oka reopened this Dec 24, 2016

Show outdated Hide outdated lib/url.js
(code >= 65/*A*/ && code <= 90/*Z*/) ||
code === 43/*+*/ ||
code === 95/*_*/||
code > 127;

This comment has been minimized.

@mscdex

mscdex Dec 24, 2016

Contributor

While we're changing things in here, I think it might be better to re-prioritize the conditionals here to optimize for the common cases. Here is what I propose:

const isVc = (code >= 97/*a*/ && code <= 122/*z*/) ||
             code === 46/*.*/ ||
             (code >= 65/*A*/ && code <= 90/*Z*/) ||
             (code >= 48/*0*/ && code <= 57/*9*/) ||
             code === 45/*-*/ ||
             code === 43/*+*/ ||
             code === 95/*_*/||
             code > 127;
@mscdex

mscdex Dec 24, 2016

Contributor

While we're changing things in here, I think it might be better to re-prioritize the conditionals here to optimize for the common cases. Here is what I propose:

const isVc = (code >= 97/*a*/ && code <= 122/*z*/) ||
             code === 46/*.*/ ||
             (code >= 65/*A*/ && code <= 90/*Z*/) ||
             (code >= 48/*0*/ && code <= 57/*9*/) ||
             code === 45/*-*/ ||
             code === 43/*+*/ ||
             code === 95/*_*/||
             code > 127;

This comment has been minimized.

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex In my opinion, that makes more sense. It looks more common in this case. Thanks a lot.

@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex In my opinion, that makes more sense. It looks more common in this case. Thanks a lot.

jun-oka added some commits Dec 1, 2016

url: stop truncating long hostname
Currently, around line 417 lib/url.js is truncating hostname and put the rest of hostname to the path if hostname length after `.`  is equal or more than 63. This behavior is different from browser behavior. I changed the code so that it doesn’t truncate.
I also added the test example which has more than 63 length in after `.`  in hostname in test url.
@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex I have applied your review which you proposed.

Contributor

jun-oka commented Dec 24, 2016

@mscdex I have applied your review which you proposed.

Show outdated Hide outdated lib/url.js
(code >= 48/*0*/ && code <= 57/*9*/) ||
code === 45/*-*/ ||
code === 43/*+*/ ||
code === 95/*_*/||

This comment has been minimized.

@mscdex

mscdex Dec 24, 2016

Contributor

minor nit: there is a missing space before the ||. I missed that in my proposed example earlier.

@mscdex

mscdex Dec 24, 2016

Contributor

minor nit: there is a missing space before the ||. I missed that in my proposed example earlier.

@jun-oka

This comment has been minimized.

Show comment
Hide comment
@jun-oka

jun-oka Dec 24, 2016

Contributor

@mscdex Thank you! I corrected it. I will be careful.

Contributor

jun-oka commented Dec 24, 2016

@mscdex Thank you! I corrected it. I will be careful.

@Trott

This comment has been minimized.

Show comment
Hide comment
@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Dec 25, 2016

Contributor

LGTM

Contributor

mscdex commented Dec 25, 2016

LGTM

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 25, 2016

Member

(arm-fanned failure on CI is infra related and unrelated to this change.)

Member

Trott commented Dec 25, 2016

(arm-fanned failure on CI is infra related and unrelated to this change.)

Trott added a commit to Trott/io.js that referenced this pull request Dec 25, 2016

url: do not truncate long hostnames
Currently, around line 417 lib/url.js is truncating hostname and put the
rest of hostname to the path if hostname length after `.`  is equal or
more than 63. This behavior is different from browser behavior. I
changed the code so that it doesn’t truncate.

I also added the test example which has more than 63 length in after
`.` in hostname in test url.

PR-URL: nodejs#9292
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Dec 25, 2016

Member

Landed in c65d55f.

Two months in the making. 🎉

Member

Trott commented Dec 25, 2016

Landed in c65d55f.

Two months in the making. 🎉

@Trott Trott closed this Dec 25, 2016

italoacasas added a commit to italoacasas/node that referenced this pull request Jan 18, 2017

url: do not truncate long hostnames
Currently, around line 417 lib/url.js is truncating hostname and put the
rest of hostname to the path if hostname length after `.`  is equal or
more than 63. This behavior is different from browser behavior. I
changed the code so that it doesn’t truncate.

I also added the test example which has more than 63 length in after
`.` in hostname in test url.

PR-URL: nodejs#9292
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>

@joyeecheung joyeecheung referenced this pull request Feb 2, 2017

Closed

test, url: break up test-url.js #11049

3 of 3 tasks complete

@jasnell jasnell referenced this pull request Apr 4, 2017

Closed

8.0.0 Release Proposal #12220

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment