User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170926190823 Steps to reproduce: Have an appcache manifest with a FALLBACK definition. An easy to reproduce example is the following site http://webdbg.com/test/appcache/ (Note: not my site, just a public example I found) Actual results: The fallback file wasn't downloaded. Therefore the whole fallback behavior isn't working. Expected results: The browser should download the fallback file and serve it in case of offline behavior.

Where is the manifest located on the server? Note we no longer allow fallback namespace and its associated fallback resource to point to a parent directory of the manifest directory (in other words - to be outside the directory where manifest resides.)

(In reply to Honza Bambas (:mayhemer) from comment #3) > Where is the manifest located on the server? > > Note we no longer allow fallback namespace and its associated fallback > resource to point to a parent directory of the manifest directory (in other > words - to be outside the directory where manifest resides.) The posted example (http://webdbg.com/test/appcache/) uses only resources at the same directory level as the manifest itself. The fallback itself is defined as / fallback.aspx The fallback.aspx is relative to the manifest file, so at the same directory level. The defined wild card at the root could be seen as a parent directory (although it is a wild card, not a specific resource). I'm not sure if this matches the situation described by you. This definition is correct with the specs - at least as far as I see. Why whould you change a deprecated API anyway?

(In reply to robert.worgul from comment #4) > (In reply to Honza Bambas (:mayhemer) from comment #3) > > Where is the manifest located on the server? > > > > Note we no longer allow fallback namespace and its associated fallback > > resource to point to a parent directory of the manifest directory (in other > > words - to be outside the directory where manifest resides.) > > The posted example (http://webdbg.com/test/appcache/) uses only resources at > the same directory level as the manifest itself. > > > The fallback itself is defined as > > / fallback.aspx But the namespace is not, it's a parent directory to where the manifest resides. > > The fallback.aspx is relative to the manifest file, so at the same directory > level. The defined wild card You refer to the "/" namespace as a wildcard? > at the root could be seen as a parent directory > (although it is a wild card, not a specific resource). I'm not sure if this > matches the situation described by you. It does. > > This definition is correct with the specs - at least as far as I see. Why > whould you change a deprecated API anyway? The behavior is likely unspecified, because the spec is likely dead. We changed the behavior because there was a valid attack vector found and it was better to break an obsolete functionality than expose it to users. If you want a fallback namespace work for the whole domain (from the root folder), then you must also put the manifest to the root and refer it from each page with an absolute path and also refer resources in it with an absolute path, obviously (we resolve relative to the manifest URL). That is the way it works now.

(In reply to Honza Bambas (:mayhemer) from comment #5) > (In reply to robert.worgul from comment #4) > > (In reply to Honza Bambas (:mayhemer) from comment #3) > > > Where is the manifest located on the server? > > > > > > Note we no longer allow fallback namespace and its associated fallback > > > resource to point to a parent directory of the manifest directory (in other > > > words - to be outside the directory where manifest resides.) > > > > The posted example (http://webdbg.com/test/appcache/) uses only resources at > > the same directory level as the manifest itself. > > > > > > The fallback itself is defined as > > > > / fallback.aspx > > But the namespace is not, it's a parent directory to where the manifest > resides. > > > > > The fallback.aspx is relative to the manifest file, so at the same directory > > level. The defined wild card > > You refer to the "/" namespace as a wildcard? Yes it is! The spec defines fallback namespaces this way: "These are URLs used as prefix match patterns for resources that are to be fetched from the network if possible, or to be replaced by the corresponding fallback entry if not." Furthermore they say: "A URL matches a fallback namespace if there exists a relevant application cache whose manifest's URL has the same origin as the URL in question, and that has a fallback namespace that is a prefix match for the URL being examined." ... with a code example mirroring our exact situation: "If a manifest http://example.com/app1/manifest declares that http://example.com/resources/images is a fallback namespace, and the user navigates to HTTP://EXAMPLE.COM:80/resources/images/cat.png, then the user agent will decide that the application cache identified by http://example.com/app1/manifest contains a namespace with a match for that URL." (Source: https://www.w3.org/TR/html5/browsers.html#concept-appcache-matches-fallback) > > > at the root could be seen as a parent directory > > (although it is a wild card, not a specific resource). I'm not sure if this > > matches the situation described by you. > > It does. > > > > > This definition is correct with the specs - at least as far as I see. Why > > whould you change a deprecated API anyway? > > The behavior is likely unspecified, because the spec is likely dead. > > We changed the behavior because there was a valid attack vector found and it > was better to break an obsolete functionality than expose it to users. > > If you want a fallback namespace work for the whole domain (from the root > folder), then you must also put the manifest to the root and refer it from > each page with an absolute path and also refer resources in it with an > absolute path, obviously (we resolve relative to the manifest URL). That is > the way it works now. For me, this is clearly breaking with the specs by being more specific than the Same-Origin-Policy.

Yes, we are breaking the spec. We are more restrictive. If you put the manifest to the root dir of the server, it will solve the problem. But I understand that you may need to keep a particular application data (manifest + the app's specific resources) in one sub-dir on the server (and use relative URLs in it) and have a shared load of resources in a different directory on the server (outside the dir where the referencing app resides.) I can't make the decision what exactly to do here on my own. This needs to be discussed mode broadly throughout our team. Appcache is broken, unsupported, and let you know that one day we are going to remove it altogether. Let you also know that there is an alternative to appcache called Service Workers [1] we are encouraging web developers to migrate from appcache to. It may not have all the features yet to migrate "just like that", but it evolves quickly. [1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API