Bug 106728 – [KURL] 'https:' gets adjusted to 'https:/'

• Status: RESOLVED
• Resolution: INVALID
• Component: Platform

[Zan Dobersek]

When creating a KURL instance with the relative URL being 'https:', the URL is adjusted to 'https:/'.

Spotted on the Coremob CSS3 Fonts test. The style rule is set to '@font-face { font-family: font; src: url(https:); }', but during parsing the URL is adjusted and the cssText attribute returns '@font-face { font-family: font; src: url(https:/); }'.
https://github.com/facebook/coremob-tests/blob/master/tests/cssfont/test.js#L38

Chromium port uses the GoogleURL but is not having this problem.

[Zan Dobersek]

The '/' gets added here:
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURL.cpp#L1358

[Zan Dobersek]

Created attachment 182465 [details]
Test patch

[Build Bot]

Comment on attachment 182465 [details]
Test patch

Attachment 182465 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15827486

New failing tests:
fast/dom/HTMLAnchorElement/set-href-attribute-host.html
fast/url/file-http-base.html
fast/dom/HTMLAnchorElement/set-href-attribute-hash.html
http/tests/misc/drag-over-iframe-invalid-source-crash.html
fast/url/segments-from-data-url.html
accessibility/image-map2.html
fast/images/crossfade-client-not-removed-crash.html
fast/ruby/before-block-doesnt-crash.html
editing/pasteboard/drop-link.html
fast/url/file.html
fast/url/standard-url.html
http/tests/misc/iframe-invalid-source-crash.html
http/tests/misc/bubble-drag-events.html
fast/ruby/generated-before-counter-doesnt-crash.html
fast/forms/submit-form-attributes.html
fast/url/relative.html
fast/url/degenerate-file-base.html
fast/loader/url-parse-1.html
fast/url/segments.html
fast/dom/HTMLAnchorElement/set-href-attribute-prevents-rebase.html
platform/mac/accessibility/document-links.html
fast/dom/HTMLAnchorElement/set-href-attribute-protocol.html
fast/ruby/before-table-doesnt-crash.html

[Benjamin Poulain]

The bug is correct ("https:" is an invalid URL, and we should not attempt to canonicalize it), but the patch is wrong.

First thing is to land a test for this if that is not already covered in existing tests.

If you are interested in improving URL parsing, I suggest you to look into WTFURL.

[Zan Dobersek]

(In reply to comment #4)
> The bug is correct ("https:" is an invalid URL, and we should not attempt to canonicalize it), but the patch is wrong.

Could you please elaborate on 'https:' being an invalid URL?

I'm using RFC 3986 as a base, and that states:

"The scheme and path components are required, though the path may be
empty (no characters).  When authority is present, the path must
either be empty or begin with a slash ("/") character."
http://tools.ietf.org/html/rfc3986#page-16

Basically, 'https:' consists of only a scheme and an empty path.
Am I missing something?

> If you are interested in improving URL parsing, I suggest you to look into WTFURL.

I've looked around a bit about WTFURL, I find it interesting. It seems though it's not currently used by any port, so I'd like to fix this problem in the scope of the old KURL implementation first.

[Benjamin Poulain]

(In reply to comment #5)
> (In reply to comment #4)
> > The bug is correct ("https:" is an invalid URL, and we should not attempt to canonicalize it), but the patch is wrong.
> 
> Could you please elaborate on 'https:' being an invalid URL?
> 
> I'm using RFC 3986 as a base, and that states:
> 
> "The scheme and path components are required, though the path may be
> empty (no characters).  When authority is present, the path must
> either be empty or begin with a slash ("/") character."
> http://tools.ietf.org/html/rfc3986#page-16
> 
> Basically, 'https:' consists of only a scheme and an empty path.
> Am I missing something?

Also read http://tools.ietf.org/html/rfc3986#section-6.2.3
And HTTP normalization.

RFC 3986 far from being the whole story, especially for the Web. You have subsequent spec defining error handling and normalization.

The following WhatWG spec is an attempt to clean things out (work in progress): http://url.spec.whatwg.org
(I actually see the "standard URL" parts has been removed since the last time I read it, so "https:" may be a valid URL nowadays...)

> > If you are interested in improving URL parsing, I suggest you to look into WTFURL.
> 
> I've looked around a bit about WTFURL, I find it interesting. It seems though it's not currently used by any port, so I'd like to fix this problem in the scope of the old KURL implementation first.

Because of the current mess in URL parsing, I have little interest in the current KURL. We really need to have a common implementation for all ports. That is why I suggested WTFURL.

[Anne van Kesteren]

KURL is gone.