[Webkit-unassigned] [Bug 54774] [fileapi] Implement LocalFileSystem.resolveFileSystemURI

[bugzilla-daemon at webkit.org]

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





--- Comment #18 from Eric U. <ericu at chromium.org>  2011-02-25 12:10:32 PST ---
(From update of attachment 83740)
View in context: https://bugs.webkit.org/attachment.cgi?id=83740&action=review

>>>> Source/WebCore/page/DOMWindow.cpp:765
>>>> +    KURL parsedURL(ParsedURLString, uri);
>>> 
>>> This still seems strange to me.  Everywhere else we call competeURL.  If this is what the spec says, it's probably wrong.  :(
>> 
>> Eric, can you comment here?  Are these URIs allowed to be relative?
> 
> Looks like there are two issues...
> 
> 1) I think this string is raw user input, if so we definitely shouldn't assume that it's a valid url. The comments on the KURL ctor being used imply that the string is known to be a valid url. I think a better ctor to parse an absolute url (of questionable validity) would be...
>    KURL(const KURL& base, const String& relative)
> ... passing in an empty KURL() as the 'base' parameter.
> 
> 2) If relative urls are supposed to be valid inputs to this scriptable method, we should be using doc->completeURL(str). I think the envisioned use case was an HTTP loaded page resolving filesystem urls... but good question... what if the page location is filesystem:something?

If the page location is already in the filesystem, then yes, relative urls should work.
You should be able to build a full static website in the filesystem, then copy it up to your server, and it should work identically in both places.

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