Closed Bug 767260 Opened 12 years ago Closed 12 years ago

window.applicationCache.mozAdd errors for https params but not for http params

Categories

(Core :: Networking: Cache, defect)

16 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nick, Unassigned)

Details

Anant and I today noticed that when passing a string URI to window.applicationCache.mozAdd it would throw security errors for params containing https but not for params using http.  We were looking at:
http://mxr.mozilla.org/mozilla-central/source/dom/src/offline/nsDOMOfflineResourceList.cpp#324
http://mxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsOfflineCacheUpdateService.cpp#520

But I don't really know anything about the code base.  This was discovered shortly after bug 767258.  I believe the same 'offline-apps.allow_by_default' preference was set true in about:config.
It looks like you can only load urls from the same scheme as the manifest :

https://mxr.mozilla.org/mozilla-central/source/dom/src/offline/nsDOMOfflineResourceList.cpp#353
Yes, we noticed that yesterday, but the question is why can't we cache a HTTP resource from a HTTPS page (like the dashboard?).

How does Gaia work around this restriction? Surely not all your app icons will be served over HTTPS?
Logging an IRC conversation about this:

<anant> mayhemer: hi, I was just looking at the implementation of window.applicationcache.mozAdd, and seems like it prevents a https site from adding a http URL to the appcache
<anant> mayhemer: looking for more info on that and to see if there are any ways we can work around it
<mayhemer> anant: yes, that is by spec
<mayhemer> I don't know how to go over this
<mayhemer> actually, I would like to eventually remove support for mozAdd
<anant> oh, the spec enforces protocol matching?
<mayhemer> dynamic entries are not speced any more
<mayhemer> yes
<anant> mayhemer: it's really useful! there's no other way to dynamically update the appcache
<Ms2ger> anant, why are you enabling mitm attacks again? :)
<anant> Ms2ger: how does that enable it? it's the https site that has to call mozAdd...
<anant> mayhemer: ok, so looks like there isn't much we can do here… anyway our use case was to be able to cache some images served off a different domain but served over http in our https app
<anant> I suspect gaia will also run into this at some point, so i'll just try and see what they have planned
<mayhemer> anant: resources in an offline cache has more or less same-origin policy
<mayhemer> anant: relative to manifest url
<anant> mayhemer: oh! but I was able to cache an external resource (different origin)… is it a bug that it was allowed?
<mayhemer> anant: I said more or less ;)
<anant> mayhemer: well, good for me, because these images I want to cache are from a different domain :)
<anant> okay, so different domain is allowed, but not different protocol.. that seems odd
<anant> but since mozAdd is our own method can't we just do whatever we want? since it's not in the spec, how can we be in violation of it if we just allow https sites to cache http resources?
<mayhemer> anant: I would have to go though the spec again
<mayhemer> anant: just put results of this conversion to the bug and I can later take a look
According this section [1] even when we would allow mozAdd add entries from different scheme, it would no load from offline cache.  This is a security model.

If you want this be changed, you need to suggest a spec change.  But IMO it will just lead to explanation of why this has been done this way.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Thanks Honza, we'll find some way to work around the restriction.
You need to log in before you can comment on or make changes to this bug.