Allow loading file:// resources that have no referrer

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Krzysztof Kowalczyk]

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.

[Krzysztof Kowalczyk]

Created attachment 13196 [details]
allow loading file:// resources with no referrer

[Brady Eidson]

I don't like this...  my gut tells me would should identify the regression, instead...

[Krzysztof Kowalczyk]

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.

[Adam Roben (:aroben)]

I think Kevin should take a look at this, as he's been doing similar work in this area to satisfy some security concerns.

[Kevin McCullough]

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?

[Kevin McCullough]

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?

[Kevin McCullough]

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.

[Krzysztof Kowalczyk]

Sounds good to me. I'll re-check this scenario after refactoring lands.