[html5] r2339 - [gwr] (2) handle captive portals better in the offline appcache feature

[whatwg at whatwg.org]

Author: ianh
Date: 2008-10-15 17:45:38 -0700 (Wed, 15 Oct 2008)
New Revision: 2339

Modified:
   index
   source
Log:
[gwr] (2) handle captive portals better in the offline appcache feature

Modified: index
===================================================================
--- index	2008-10-16 00:33:17 UTC (rev 2338)
+++ index	2008-10-16 00:45:38 UTC (rev 2339)
@@ -34510,11 +34510,24 @@
 
      </li>
 
-     <li><p>If the previous steps fails (e.g. the server returns a 4xx
-     or 5xx response or equivalent, or there is a DNS error, or the
-     connection times out, or the user cancels the download), then run
-     the <a href=#cache-failure-steps>cache failure steps</a>.</li>
+     <li>
 
+      <p>If the previous steps fails (e.g. the server returns a 4xx or
+      5xx response or equivalent, or there is a DNS error, or the
+      connection times out, or the user cancels the download), or if
+      the server returned a redirect, then run the <a href=#cache-failure-steps>cache failure
+      steps</a>.</p>
+
+      <p class=note>Redirects are fatal because they are either
+      indicative of a network problem (e.g. a captive portal); or
+      would allow resources to be added to the cache under URLs that
+      differ from any URL that the networking model will allow access
+      to, leaving orphan entries; or would allow resources to be
+      stored under URLs different than their true URLs. All of these
+      situations are bad.</p>
+
+     </li>
+
      <li><p>Otherwise, the fetching succeeded. Store the resource in
      the <var title="">new cache</var>.</li>
 
@@ -34562,10 +34575,11 @@
     in the cache manifest, then it might still be being
     downloaded.</p>
 
-    <p>If any of these downloads fail (e.g. the server returns a 4xx
-    or 5xx response or equivalent, or there is a DNS error, or the
-    connection times out, or the user cancels the download), then run
-    the <a href=#cache-failure-steps>cache failure steps</a>.</p>
+    <p>If any of these downloads fail (e.g. the connection times out,
+    or the user cancels the download), then run the <a href=#cache-failure-steps>cache
+    failure steps</a>.</p> <!-- can't fail with a non-2xx code,
+    because things only get added to the cache implicitly once they
+    are known to have a manifest="" attribute. -->
 
    </li>
 
@@ -34803,12 +34817,15 @@
     the <a href=#application-cache>application cache</a> whose <path> component is
     a <a href=#prefix-match>prefix match</a> for the resource's URL's <a href=#url-path title=url-path><path></a> component, then:</p>
 
-    <p><a href=#fetch>Fetch</a> the resource normally. If this results 4xx
-    or 5xx status codes or equivalent, or if there were network errors
-    (but not if the user canceled the download), then instead get,
-    from the cache, the resource of the <a href=#concept-appcache-fallback title=concept-appcache-fallback>fallback entry</a>
-    corresponding to the namespace with the longest matching <a href=#url-path title=url-path><path></a> component. Abort these
-    steps.</p>
+    <p><a href=#fetch>Fetch</a> the resource normally. If this results in a
+    redirect to a resource with another <a href=#origin-0>origin</a>
+    (indicative of a captive portal), or a 4xx or 5xx status code or
+    equivalent, or if there were network errors (but not if the user
+    canceled the download), then instead get, from the cache, the
+    resource of the <a href=#concept-appcache-fallback title=concept-appcache-fallback>fallback
+    entry</a> corresponding to the namespace with the longest
+    matching <a href=#url-path title=url-path><path></a>
+    component. Abort these steps.</p>
 
    </li>
 
@@ -34972,9 +34989,9 @@
 
    <li><p><a href=#fetch>Fetch</a> the resource referenced by <var title="">url</var>.</li>
 
-   <li><p>If this results 4xx or 5xx status codes or equivalent, or if
-   there were network errors, or if the user canceled the download,
-   then abort these steps.</li>
+   <li><p>If this results in a redirect, or a 4xx or 5xx status code
+   or equivalent, or if there were network errors, or if the user
+   canceled the download, then abort these steps.</li>
 
    <li>
 
@@ -35682,7 +35699,10 @@
     the browsing context being navigated is a <a href=#top-level-browsing-context>top-level browsing
     context</a>, and the navigation attempt failed (e.g. the server
     returned a 4xx or 5xx status code or equivalent, or there was a
-    DNS error), then:</p>
+    DNS error), then:</p> <!-- note that a redirect can never reach
+    this point as it is handled earlier, meaning that a captive portal
+    captures URLs in fallback namespaces and you can't ever get to the
+    fallback file of a resource if you have a captive portal -->
 
     <p>Let <var title="">candidate</var> be the <a href=#concept-appcache-fallback title=concept-appcache-fallback>fallback resource</a>
     specified for the <a href=#concept-appcache-fallback-ns title=concept-appcache-fallback-ns>fallback namespace</a> in

Modified: source
===================================================================
--- source	2008-10-16 00:33:17 UTC (rev 2338)
+++ source	2008-10-16 00:45:38 UTC (rev 2339)
@@ -39191,11 +39191,24 @@
 
      </li>
 
-     <li><p>If the previous steps fails (e.g. the server returns a 4xx
-     or 5xx response or equivalent, or there is a DNS error, or the
-     connection times out, or the user cancels the download), then run
-     the <span>cache failure steps</span>.</p></li>
+     <li>
 
+      <p>If the previous steps fails (e.g. the server returns a 4xx or
+      5xx response or equivalent, or there is a DNS error, or the
+      connection times out, or the user cancels the download), or if
+      the server returned a redirect, then run the <span>cache failure
+      steps</span>.</p>
+
+      <p class="note">Redirects are fatal because they are either
+      indicative of a network problem (e.g. a captive portal); or
+      would allow resources to be added to the cache under URLs that
+      differ from any URL that the networking model will allow access
+      to, leaving orphan entries; or would allow resources to be
+      stored under URLs different than their true URLs. All of these
+      situations are bad.</p>
+
+     </li>
+
      <li><p>Otherwise, the fetching succeeded. Store the resource in
      the <var title="">new cache</var>.</p></li>
 
@@ -39249,10 +39262,11 @@
     in the cache manifest, then it might still be being
     downloaded.</p>
 
-    <p>If any of these downloads fail (e.g. the server returns a 4xx
-    or 5xx response or equivalent, or there is a DNS error, or the
-    connection times out, or the user cancels the download), then run
-    the <span>cache failure steps</span>.</p>
+    <p>If any of these downloads fail (e.g. the connection times out,
+    or the user cancels the download), then run the <span>cache
+    failure steps</span>.</p> <!-- can't fail with a non-2xx code,
+    because things only get added to the cache implicitly once they
+    are known to have a manifest="" attribute. -->
 
    </li>
 
@@ -39540,14 +39554,15 @@
     a <span>prefix match</span> for the resource's URL's <span
     title="url-path"><path></span> component, then:</p>
 
-    <p><span>Fetch</span> the resource normally. If this results 4xx
-    or 5xx status codes or equivalent, or if there were network errors
-    (but not if the user canceled the download), then instead get,
-    from the cache, the resource of the <span
-    title="concept-appcache-fallback">fallback entry</span>
-    corresponding to the namespace with the longest matching <span
-    title="url-path"><path></span> component. Abort these
-    steps.</p>
+    <p><span>Fetch</span> the resource normally. If this results in a
+    redirect to a resource with another <span>origin</span>
+    (indicative of a captive portal), or a 4xx or 5xx status code or
+    equivalent, or if there were network errors (but not if the user
+    canceled the download), then instead get, from the cache, the
+    resource of the <span title="concept-appcache-fallback">fallback
+    entry</span> corresponding to the namespace with the longest
+    matching <span title="url-path"><path></span>
+    component. Abort these steps.</p>
 
    </li>
 
@@ -39733,9 +39748,9 @@
    <li><p><span>Fetch</span> the resource referenced by <var
    title="">url</var>.</p></li>
 
-   <li><p>If this results 4xx or 5xx status codes or equivalent, or if
-   there were network errors, or if the user canceled the download,
-   then abort these steps.</p></li>
+   <li><p>If this results in a redirect, or a 4xx or 5xx status code
+   or equivalent, or if there were network errors, or if the user
+   canceled the download, then abort these steps.</p></li>
 
    <li>
 
@@ -40564,7 +40579,10 @@
     the browsing context being navigated is a <span>top-level browsing
     context</span>, and the navigation attempt failed (e.g. the server
     returned a 4xx or 5xx status code or equivalent, or there was a
-    DNS error), then:</p>
+    DNS error), then:</p> <!-- note that a redirect can never reach
+    this point as it is handled earlier, meaning that a captive portal
+    captures URLs in fallback namespaces and you can't ever get to the
+    fallback file of a resource if you have a captive portal -->
 
     <p>Let <var title="">candidate</var> be the <span
     title="concept-appcache-fallback">fallback resource</span>