[whatwg] Can we change the base URL of fallback entries in appcache manifests? and other feedback

On Tue, 2 Aug 2011, Michael Nordman wrote:
> > On Mon, 13 Jun 2011, Michael Nordman wrote:
> > >
> > > Let's say there's a page in the cache to be used as a fallback 
> > > resource, refers to the manifest by relative url...
> > >
> > > <html manifest='x'>
> > >
> > > Depending on the url that invokes the fallback resource, 'x' will be 
> > > resolved to different absolute urls. When it doesn't match the 
> > > actual manifest url, the fallback resource will get tagged as 
> > > FOREIGN and will no longer be used to satisfy main resource loads.
> > >
> > > I'm not sure if this is a bug in chrome or a bug in the appcache 
> > > spec just yet. I'm pretty certain that Safari will have the same 
> > > behavior as chrome in this respect (the same bug). The value of the 
> > > manifest attribute is interpreted as relative to the location of the 
> > > loaded document in chrome and all webkit based browsers and that 
> > > value is used to detect foreign'ness.
> > >
> > > The workaround/solution for this is to NOT put a manifest attribute 
> > > in the <html> tag of the fallback resource (or to put either an 
> > > absolute url or host relative url as the manifest attribute value).
> >
> > Or just make sure you always use relative URLs, even in the manifest.
> >
> > I don't really understand the problem here. Can you elaborate further?
>
> Suppose the fallback resource is setup like this...
> 
> FALLBACK:
> / FallbackPage.html
> 
> ... and that page contains a relative link to the manifest in its
> <html> tag like so...
> <html manifest=file.manifest>
> 
> Any server request that fails under / will get FallbackPage.html in
> response. For example...
> 
> /SomePage.html
> 
> When the fallback is used in this case the manifest url will be
> interpreted as /file.manifest
> 
> /Some/Other/Page.html
> 
> And in this case the manifest url will be interpreted as
> /Some/Other/file.manifest

Ah, I see. Yes, that's an interesting point. We could have fallback pages 
say that their default base URL is the URL of the fallback page... would 
implementations be willing to do that?


> On Fri, 1 Jul 2011, Michael Nordman wrote:
> > >
> > > Cross-origin resources listed in the CACHE section aren't retrieved 
> > > with the 'Origin' header
> >
> > This is incorrect. They are fetched with the origin of the manifest. 
> > What makes you say no Origin header is included?
> 
> I don't see mention of that in the draft?

The algorithm for updating the cache explicitly says:

   "Fetch the resource, from the origin of the URL /manifest URL/"


> I'm not familiar with CORS usage. Do xorigin subresource loads of all 
> kinds (.js, .css, .png) carry the Origin header?

Depends on how the "fetch" algorithm is invoked.


On Wed, 3 Aug 2011, Cameron Heavon-Jones wrote:
> >>>
> >>> There are definite UX limitations to that approach - the content 
> >>> can't provide visual hinting during the autocomplete, for example 
> >>> (it would be nice if a photo gallery could trim down the set of 
> >>> photos from my friends as I narrow in on the name).
> >> 
> >> This would seems to be ok as long as the contents remain sandboxed 
> >> until selection is confirmed.
> > 
> > Assuming the photos are server-side, there's no way to do this without 
> > giving the app essentially full read access to the contacts.
> 
> My assumption was that this was client-side.

I don't see how one's friends' photos could be client side.


> It makes no difference though, in the case of file selection through a 
> modal dialog, the requesting page has no knowledge of if the file is 
> coming from a local hard drive or networked resource, this is the power 
> of the abstraction. It works the same for network-only resources.

I don't follow.


On Wed, 3 Aug 2011, Michael Nordman quoted a developer as saying:
> 
> Docs maintains a set of appcaches which it uses for various purposes. 
> Each editor, for example, has a cache.  There are also cases where 
> different documents require different versions of the same editor.
>
> The set of caches required on a particular browser depends on the 
> documents synced there.  A given set of documents will require a 
> particular (much smaller) set of caches to open.  The set of caches 
> required on a given browser is therefore dynamic, changing as documents 
> enter and leave the set of those synchronized.

That seems very confused. Appcache is designed so that you can cache the 
applicaton (the editor) separately from the documents. The documents would 
go into a client-side database.

This is similar to how desktop software works. You don't install a new 
copy of WordPerfect for every document you create.

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

Received on Monday, 7 May 2012 13:40:28 UTC