RESOLVED DUPLICATE of bug 54090 21979
KURL doesn't canonicalize redundant port numbers 
https://bugs.webkit.org/show_bug.cgi?id=21979
Summary KURL doesn't canonicalize redundant port numbers
Brett Wilson (Google)
Reported 2008-10-30 11:48:11 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Thiago Marcos P. Santos
Comment 1 2012-05-18 01:38:43 PDT
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.
Thiago Marcos P. Santos
Comment 2 2012-05-18 02:42:29 PDT
(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?
Adam Barth
Comment 3 2012-05-18 04:51:25 PDT
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.
Alexey Proskuryakov
Comment 4 2012-05-18 11:23:02 PDT
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 ***
Note You need to log in before you can comment on or make changes to this bug.