- From: poot <cvsmail@w3.org>
- Date: Sun, 10 Jan 2010 20:46:38 +0900 (JST)
- To: public-html-diffs@w3.org
hixie: Plug a security hole with appcache: don't allow hostile https: servers to cache no-store files on other https: servers. Also, mention that https: apps can be made to work offline. (whatwg r4557) http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.3636&r2=1.3637&f=h http://html5.org/tools/web-apps-tracker?from=4556&to=4557 =================================================================== RCS file: /sources/public/html5/spec/Overview.html,v retrieving revision 1.3636 retrieving revision 1.3637 diff -u -d -r1.3636 -r1.3637 --- Overview.html 10 Jan 2010 11:03:22 -0000 1.3636 +++ Overview.html 10 Jan 2010 11:46:27 -0000 1.3637 @@ -41046,7 +41046,11 @@ files and make them available even when the user is offline.<p class="note">Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly - mentioned.<h5 id="appcacheevents"><span class="secno">6.9.1.1 </span>Event summary</h5><p class="XXX annotation"><b>Status: </b><i>Last call for comments</i><p><i>This section is non-normative.</i><p>When the user visits a page that declares a manifest, the browser + mentioned.<p class="note">HTTP cache headers and restrictions on caching pages + served over TLS (encrypted, using <code title="">https:</code>) are + overridden by manifests. Thus, pages will not expire from an + application cache before the user agent has updated it, and even + applications served over TLS can be made to work offline.<h5 id="appcacheevents"><span class="secno">6.9.1.1 </span>Event summary</h5><p class="XXX annotation"><b>Status: </b><i>Last call for comments</i><p><i>This section is non-normative.</i><p>When the user visits a page that declares a manifest, the browser will try to update the cache. It does this by fetching a copy of the manifest and, if the manifest has changed since the user agent last saw it, redownloading all the resources it mentions and caching them @@ -41404,7 +41408,10 @@ --> </dl><p>Manifests may contain sections more than once. Sections may be - empty.<p>URLs that are to be fallback pages associated with <a href="#concept-appcache-fallback-ns" title="concept-appcache-fallback-ns">fallback namespaces</a>, and + empty.<p>If the manifest's <a href="#url-scheme" title="url-scheme"><scheme></a> + is <code title="">https:</code> or another scheme intended for + encrypted data transfer, then all URLs in <a href="#concept-appcache-manifest-explicit" title="concept-appcache-manifest-explicit">explicit sections</a> + must have the <a href="#same-origin">same origin</a> as the manifest itself.<p>URLs that are to be fallback pages associated with <a href="#concept-appcache-fallback-ns" title="concept-appcache-fallback-ns">fallback namespaces</a>, and those namespaces themselves, must be given in <a href="#concept-appcache-manifest-fallback" title="concept-appcache-manifest-fallback">fallback sections</a>, with the namespace being the first URL of the data line, and the corresponding fallback page being the second URL. All the other @@ -41582,7 +41589,10 @@ <a href="#url-scheme" title="url-scheme"><scheme></a> component than the manifest's URL (compared in an <a href="#ascii-case-insensitive">ASCII case-insensitive</a> manner), then jump back to the step - labeled "start of line".</p> + labeled "start of line". If the manifest's <a href="#url-scheme" title="url-scheme"><scheme></a> is <code title="">https:</code> or another scheme intended for encrypted + data transfer, and the resulting <a href="#absolute-url">absolute URL</a> does + not have the <a href="#same-origin">same origin</a> as the manifest's URL, + then jump back to the step labeled "start of line".</p> <p>Drop the <a href="#url-fragment" title="url-fragment"><fragment></a> component of the resulting <a href="#absolute-url">absolute URL</a>, if it has
Received on Sunday, 10 January 2010 11:47:07 UTC