[whatwg] Caching offline Web applications

Mon Nov 17 20:05:08 PST 2008

On Tue, 21 Oct 2008, Dave Camp wrote:
> >>
> >> > Made application caches scoped to their browsing context, and 
> >> > allowed iframes to start new scopes. By default the contents of an 
> >> > iframe are part of the appcache of the parent, but if you declare a 
> >> > manifest, you get your own cache.
> >>
> >> Should this inheritance be subject to the same origin restriction 
> >> enforced while selecting a cache during navigation?
> >
> > The same-origin restriction is intended to prevent people from setting 
> > up their manifests such that another site will stop being fetched from 
> > the net. In an iframe, the risk isn't present, since you have to go to 
> > the evil site in the first place, and it has to explicitly pick the 
> > victim site in an iframe. Since you can't tell what the URL of the 
> > victim iframe content is anyway, there's no practical difference 
> > between it being on a remote site or the same site, as far as i can 
> > tell.
> >
> > No?
> 
> Yeah, but it does let an evil site persist a potential dom-based xss 
> attack permanently.  It still depends on you visiting the evil site 
> repeatedly, though.

Based on this and other offline feedback (no pun intended), I've changed 
the spec to make <iframe>s never inherit the manifest.

On Wed, 22 Oct 2008, Michael Nordman wrote:
> >> 
> >> * intercept namespaces [new]
> >> This form of namespace is not in the spec at present. This is a 
> >> proposal to add it. It is a heavily used feature of the Gears 
> >> LocalServer. The basic idea is to intercept requests into this 
> >> namespace and satisfy them with a cached 'namespace-handler' without 
> >> consulting the server.
> >>
> >> 2) Hijacking parameterized requests and returning a local resource 
> >> without incurring any network traffic.
> >
> > This isn't supported; the network is always consulted. But if the 
> > network request fails, then a fallback resource is used, though it 
> > cannot be generated on the fly.
> 
> Why? I had assumed this was a simple omission in the original draft. Can 
> you explain the rationale behind not having this feature? What am i 
> missing?

The rationale for not having any feature is the same -- there was either 
not enough rationale for adding it, or the rationale didn't outweigh the 
cost of adding it at this stage. This is something we can delay until a 
later version. It's more important to get interoperable behavior sooner 
than to get a complete API later.

On Wed, 29 Oct 2008, Honza Bambas wrote:
>
> The spec says when an iframe (a child browsing context) doesn't refer a 
> manifest in the <html> tag it has to inherit cache from its parent's 
> document.

I have removed this requirement.

> Potentially, to preserve inheritance and save some work to web 
> developers, we may introduce explicit attribute to iframe by defining 
> the manifest to use or just say to let the context inherit the cache 
> from the parent.

If the document in the iframe has the same manifest (and is itself listed 
in the manifest so it is cached before going offline) then it'll all 
continue working fine. Only things like images or documents that don't 
have a manifest would be a problem.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'