Summary: | Add URL scheme parsing tests | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Barth <abarth> | ||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, dbates, fishd, mjs | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Other | ||||||
OS: | OS X 10.5 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 37641 | ||||||
Attachments: |
|
Description
Adam Barth
2010-04-13 01:10:13 PDT
Created attachment 53231 [details]
Patch
Could it be correct behavior that " HTTP " is treated as a relative URL? Maybe it should never hit the "absolute URL" case, in fact? > Could it be correct behavior that " HTTP " is treated as a relative URL? Maybe
> it should never hit the "absolute URL" case, in fact?
Yes, I believe that is the correct behavior. However, it makes it tricky to test how we parse absolute URLs that begin in this way.
That would mean testing a code path that should never be taken. It seems better to just test that this code path is never taken by verifying that such URLs are parsed as relative. > That would mean testing a code path that should never be taken. There might be another API that takes strings and parses them as absolute URLs, or if there isn't one today, we could well invent one tomorrow. > It seems better > to just test that this code path is never taken by verifying that such URLs are > parsed as relative. We can certainly test that if you like. The intent of this test is to test the URL parser, not the HTMLAnchorElement.href API. We're just using the href API as a convenient way to get at the URL parser. Comment on attachment 53231 [details]
Patch
r=me
Committed r57635: <http://trac.webkit.org/changeset/57635> |