[whatwg] In AppCache web apps, images from unpredictable domains won't load
Michael Nordman
michaeln at google.com
Mon Jul 6 18:17:09 PDT 2009
On Mon, Jul 6, 2009 at 2:40 PM, Aaron Boodman <aa at google.com> wrote:
> On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking<jonas at sicking.cc> wrote:
> > On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyte<awhyte at google.com> wrote:
> >> When a page is loaded from an AppCache, even when online, external
> resources
> >> such as images will not be loaded at all.
> >> If foo.com has an image <img src="http://bar.com/img.png" />, then
> according
> >> to the steps in
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel
> >> it will fail the load for the resource.
> >> For example, someone with an Offline Gmail client would never be able to
> see
> >> cross-domain images in emails, even when completely online.
> >> There's no workaround in the current spec.
> >
> > The workaround is for the gmail to download the images to gmails
> > servers and then serve them from a google domain. Not as simple as
> > simply being able to cache urls from other servers I agree, but doing
> > multi domain application caches is very complicated from a security
> > point of view so I think we wanted to stay clear of it for the first
> > iteration of the spec.
>
> The spec already provides for loading resources not in the app cache
> from the network (across origins or not). It simply defaults to not
> allowing it. You have to opt-into the url prefixes you want to load
> from the network.
>
> I think we could fix this issue by simply changing the rules to
> default to allowing requests, and having the author mark the url
> prefixes he wants to blacklist from being loaded from the network.
That would work too. We'd have to introduce a new kind of 'namespace' in the
manifest file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/e88a1ff8/attachment.htm>
More information about the whatwg
mailing list