From the W3C spec (http://www.w3.org/TR/2011/WD-html5-20110525/offline.html) If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself. The practical effect of this rule is that media served from a CDN cannot be included in the cache manifest without triggering a Mixed Content warning. This conflicts with common development and scalability best practices. Chrome notably ignores this part of the spec, and no issues are reported for using secure CDNs that do not match the primary origin. We've abandoned appcache on Marketplace over this issue.

(In reply to Potch [:potch] from comment #0) > From the W3C spec (http://www.w3.org/TR/2011/WD-html5-20110525/offline.html) > > If the manifest's <scheme> is https: or another scheme intended for > encrypted data transfer, then all URLs in explicit sections must have the > same origin as the manifest itself. > > The practical effect of this rule is that media served from a CDN cannot be > included in the cache manifest without triggering a Mixed Content warning. > This conflicts with common development and scalability best practices. > Chrome notably ignores this part of the spec, and no issues are reported for > using secure CDNs that do not match the primary origin. > > We've abandoned appcache on Marketplace over this issue. The latest version of the spec has removed this restriction: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html http://www.w3.org/TR/html5/browsers.html#offline Search for "https" and you will see that the statement is gone. This should be very easy to fix and we should fix it for basecamp because it will likely affect a lot of web apps that try to use AppCache.

That's great news! Glad I was looking at an old version of the spec.

(In reply to Brian Smith (:bsmith) from comment #1) > > The practical effect of this rule is that media served from a CDN cannot be > > included in the cache manifest without triggering a Mixed Content warning. > > This conflicts with common development and scalability best practices. > > Chrome notably ignores this part of the spec, and no issues are reported for > > using secure CDNs that do not match the primary origin. Potch, are you sure that his is what is causing the mixed content warning? AppCache semantics say that if something is rejected by the AppCache download/update rules, then the AppCache app will fail to download/install at all. I suspect that if you are seeing the broken lock icon, that the cause is bug 794507 or something else. Do you have a test case?

I agree with brian. I never understood how offline cache could be involved in mixed content warning and how "not enforcing the same-origin for HTTPS cache manifests" would help. By the way, the title of this bug doesn't makes sense to me at all! Where and what against what we should loosen that you believe restricts same origin rule in app cache code or spec? To clear the things up (all is by the spec and we're implementing it): - when a document refers a manifest, the manifest URL must be the same origin as the document, always, regarding of being http or https scheme - explicit entries must have the same scheme, but not same origin as the manifest ; when different scheme is found, we just ignore the entry - fallback targets (the URL to load actually) and namespaces must both be the same origin ; we ignore the entry when the check fail ; this is a must (I encountered this recently, just need to find the reason again Update fails when any item redirects with 30X result. Update fails when any item redirects *internally* to a different scheme (HSTS, bug 826766).

(In reply to Potch [:potch] from comment #0) > From the [old version of the] W3C spec (http://www.w3.org/TR/2011/WD-html5-20110525/offline.html) > > If the manifest's <scheme> is https: or another scheme intended for > encrypted data transfer, then all URLs in explicit sections must have > the same origin as the manifest itself. Honza, the title of this bug is referencing this old, removed, same-origin restriction. Looking at the code, I did not see any place where we enforce a same-origin restriction (only same-scheme) on explicit resources. I suspect this bug should be RESOLVED WORKSFORME.

(In reply to Brian Smith (:bsmith) from comment #5) > (In reply to Potch [:potch] from comment #0) > > From the [old version of the] W3C spec (http://www.w3.org/TR/2011/WD-html5-20110525/offline.html) > > > > If the manifest's <scheme> is https: or another scheme intended for > > encrypted data transfer, then all URLs in explicit sections must have > > the same origin as the manifest itself. > > Honza, the title of this bug is referencing this old, removed, same-origin > restriction. Looking at the code, I did not see any place where we enforce a > same-origin restriction (only same-scheme) on explicit resources. I suspect > this bug should be RESOLVED WORKSFORME. We've never implemented anything like that.

I have cleared the basecamp nom on this bug as it doesn't read as though there is consensus that this is an issue. Please renom if this is clearly a blocking issue with a comment to clarify what will be done in this bug.

Hey guys, I believe I am experiencing the same issue. I use the appcache, and my site is served over SSL. On the first page load, the lock shows and everything is fine. The appcache downloads, and any subsequent page refresh shows the globe, and not the lock icon anymore. Now, I do not use the same origin policy, as my application server is where my manifest and html files are stored, and all of my assets are servered over SSL via Amazon S3. Can anybody please direct me on what I should do to resolve this, or give me any helpful information? thanks, Lee

(In reply to Lee Farrell from comment #8) > Can anybody please direct me on what I should do to resolve this, or give me > any helpful information? Your problem sounds like bug 794507. Unfortunately, it requires a fix in our code and until bug 794507 is fixed, the only safe workarounds are (a) keep the lock by not using AppCache for HTTPS content, or (b) ignore the fact that the lock icon switches to the globe and keep on using AppCache with your HTTPS content. Note that, as far as bug 794507 goes, your app should actually keep working fine even though the lock icon switches to the globe.

Hey Brian. We depend heavily on the appcache, so we cannot dump it. Our customers are suspicious that the lock does not show. It the bug to be fixed do you know? thanks

(In reply to Brian Smith (:bsmith) from comment #5) > Honza, the title of this bug is referencing this old, removed, same-origin > restriction. Looking at the code, I did not see any place where we enforce a > same-origin restriction (only same-scheme) on explicit resources. I suspect > this bug should be RESOLVED WORKSFORME. Since Honza said "We've never implemented anything like that," and because I verified that the code isn't doing any same-origin check, and because this bug seems to be causing confusion, I am resolving it INVALID. Please re-open if you disagree.

Also, I responded to Lee's comment 10 in bug 794507. Lee, thanks for commenting here and please comment in bug 794507 if you have more input to give us.

Thanks for getting this sorted!

Batch edit: Bugs marked status-b2g18: affected after 2/13 branching of v1.0.1 are now also status-b2g18-v1.0.1: affected