Bug 21979
| Summary: | KURL doesn't canonicalize redundant port numbers | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brett Wilson (Google) <brettw> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | abarth, ap, tmpsantos |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 37641 | ||
Brett Wilson (Google)
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
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
(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
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
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 ***