|Summary:||Allow loading file:// resources that have no referrer|
|Product:||WebKit||Reporter:||Krzysztof Kowalczyk <kkowalczyk>|
|Component:||New Bugs||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, aroben, kmccullough|
|OS:||OS X 10.4|
Description Krzysztof Kowalczyk 2007-02-15 20:25:04 PST
Currently loading file:// resource that doesn't also have file:// referrer will fail because FrameLoader::canLoad() returns false. That means that unless special steps are taken in the upper layer to fake a file:// referrer, loading a file:// resource given e.g. in a command-line or entered directly in the url bar will fail. It certainly does in gdk build since all it does is Frame::loader()::load(url) which ends up passing an empty string as a referrer to FrameLoader::canLoad(). For gdk build it's a regression because it used to work. I tried to track down the change that might have caused that but failed (too many changes to FrameLoader.cpp). The fix is to change FrameLoader::canLoad() to return true if url is a file and referrer is an empty string.
Comment 1 Krzysztof Kowalczyk 2007-02-15 20:25:52 PST
Created attachment 13196 [details] allow loading file:// resources with no referrer
Comment 2 Brady Eidson 2007-02-15 21:47:46 PST
I don't like this... my gut tells me would should identify the regression, instead...
Comment 3 Krzysztof Kowalczyk 2007-02-15 22:48:00 PST
This code has been added with change http://trac.webkit.org/projects/webkit/changeset/18635 when mac-only code was made cross-platform. Is it incorrect to expect Frame::loader()::load(url) to work when url is file:// ? If yes, what is recommended way to load file:// url when all I have is Frame? Looking at canLoad() logic I see no justification for refusing loading file:// requests that don't have file:// referrer because it seems like a valid scenario. How would I load that first file:// url? I could fake the referrer just to satisfy canLoad(). This is what FrameLoader::begin() seem to be doing by setting m_outgoingReferrer to the copy of the url, but that doesn't sound like the right solution.
Comment 4 Adam Roben (:aroben) 2007-02-16 23:05:21 PST
I think Kevin should take a look at this, as he's been doing similar work in this area to satisfy some security concerns.
Comment 5 Kevin McCullough 2007-02-19 10:53:49 PST
canLoad() is going to change significantly, shortly, and I will be chaning all of the callers. If the only reason callers are using outgoingReferer() is to placate canLoad(), then I'm not opposed to allowing empty refererrs. A lot of the applications that build there own dom have "about:blank" as there referer, but set the SubstitueData of a document as valid. Would checking if the SubstituteData is valid be an acceptable alternative to allowing blank urls? If not, is there any security vulnerability created by allowing blank urls?
Comment 6 Kevin McCullough 2007-02-19 14:35:19 PST
I'm still researching, but one example of a concern would be if someone somehow blocked their referrer, would they then be allowed to load local resources?
Comment 7 Kevin McCullough 2007-02-19 17:19:58 PST
Comment on attachment 13196 [details] allow loading file:// resources with no referrer r- because this will be incorportated into, soon to deploy, refactoring work in this area.
Comment 8 Krzysztof Kowalczyk 2007-02-19 18:19:00 PST
Sounds good to me. I'll re-check this scenario after refactoring lands.