21979 2008-10-30 11:48:11 -0700 KURL doesn't canonicalize redundant port numbers 2012-05-18 11:23:02 -0700 1 1 1 Unclassified WebKit Platform 528+ (Nightly build) All All RESOLVED DUPLICATE 54090 P2 Normal --- 37641 1 brettw webkit-unassigned abarth ap tmpsantos oldest_to_newest 97144 0 brettw 2008-10-30 11:48:11 -0700 KURL doesn't strip port numbers that are redundant according to the current scheme. For example, "http://apple.com:80/foo" will keep the ":80". This is not a canonical form. This will cause problems with link coloring, and perhaps in other parts of the system. NSURL seems to do this properly, and it gets stripped at a later point in the loading process. But it seems that everybody should agree about what this URL is. 627466 1 tmpsantos 2012-05-18 01:38:43 -0700 I have a similar problem here that might be related to this. I get 0 as port number when calling SecurityOrigin::port() if the port is the default port number for the protocol (i.e http://foobar/ or http://foobar:80/). IMO it should return 80. If I have, let's say, http://foobar:123/, it returns 123 as expected. 627516 2 tmpsantos 2012-05-18 02:42:29 -0700 (In reply to comment #1) > I have a similar problem here that might be related to this. > > I get 0 as port number when calling SecurityOrigin::port() if the port is the default port number for the protocol (i.e http://foobar/ or http://foobar:80/). IMO it should return 80. > > If I have, let's say, http://foobar:123/, it returns 123 as expected. Looks like that both KURL and SecurityOrigin clears the port when it is the default port. Does anyone knows why? 627569 3 abarth 2012-05-18 04:51:25 -0700 It's important for compatibility that SecurityOrigin canonicalize the port. I don't think it matters if it canonicalizes to 0 or to the default port number, although it might impact the identifiers for persistent storage, so we'll need to be careful if we change it. 627844 4 ap 2012-05-18 11:23:02 -0700 The original issue reported here has been fixed in bug 54090. It's best to file separate bugs for related issues, or to discuss them on our mailing lists. > This will cause problems with link coloring In fact, link coloring used to work, and got broken by this change, which is tracked as bug 78358. *** This bug has been marked as a duplicate of bug 54090 ***