- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 10 Jan 2010 11:46:31 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv12668
Modified Files:
Overview.html
Log Message:
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)
Index: Overview.html
===================================================================
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:46:32 UTC