[Webkit-unassigned] [Bug 46982] Setting href protocol attribute on malformed URL is incorrect when page is served over HTTP

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=46982


Steve Block <steveblock at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steveblock at google.com




--- Comment #3 from Steve Block <steveblock at google.com>  2010-10-04 05:28:10 PST ---
Considering your simpler test case ...
  Served from http://host/path
  document.createElement('a').href = 'http:?query';

'http://host/path?query' is the correct result provided we're following the non-strict parsing rules defined at http://tools.ietf.org/html/rfc3986#section-5.2.2. I think that the logic you mention at line 401 of KURL.cpp is providing exactly this non-strict parsing - we ignore the scheme if it's the same as that of the base URI.

If we were to use the strict parsing rules, then the result should be 'http:?query'. This matches the case when the scheme doesn't match that of the base URI, as is the case when the layout tests are served from file://.


As for the test case I originally mentioned, this still looks like a bug to me, as the protocol is being set on the resolved URL, which should be 'foo:?query' ...
  Served from http://host/path
  a.href = "foo:?query";
  a.protocol = "http";
  shouldBe("a.href", "'http:?query'");

Chromium (including ToT WebKit): FAIL - http://host/?query
Safari (including ToT WebKit)  : FAIL - http://host/path?query
Android (including ToT WebKit) : FAIL - http://host/path?query

Note that the reverse case works as expected ...
  Served from http://host/path
  a.href = "http:?query";
  a.protocol = "foo";
  shouldBe("a.href", "'foo://host/path?query'");

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.