HTML Standard Tracker

Filter

File a bug

SVNBugCommentTime (UTC)
2348[Gecko] [Webkit] [Google Gears] Appcache: Handle errors for dynamic and master entries differently, since they aren't representative of manifest errors.2008-10-17 22:38
@@ -39249,33 +39249,74 @@ style/default.css</pre>
       satisfy the <code>img</code> element on the page, as well as
       being listed in the cache manifest. According to the rules for
       <span title="fetch">fetching</span> that image only need be
       downloaded once, and it can be used both for the cache and for
       the rendered Web page.</p>
 
      </li>
 
      <li>
 
-      <p>If the previous steps fails (e.g. the server returns a 4xx or
+      <p>If the previous step 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>
+      the server returned a redirect, then run the first appropriate
+      step from the following list:</p>
+
+      <dl class="switch">
+
+       <dt>If the URL being processed was flagged as an "explicit
+       entry" or a "fallback entry"</dt>
+
+       <dd>
+
+        <p>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>
+
+       </dd>
+
+       <dt>If the error was a 404 or 410 HTTP response or
+       equivalent</dt>
+
+       <dd>
+
+        <p>Skip this resource. It is dropped from the cache.</p>
+
+       </dd>
+
+       <dt>Otherwise</dt>
+
+       <dd>
+
+        <p>Copy the resource and its metadata from <var
+        title="">cache</var>, and ignore the resource obtained from
+        the network.</p>
+
+       </dd>
+
+      </dl>
+
+      <p>User agents may warn the user of these errors as an aid to
+      development.</p>
+
+      <p class="note">These rules make errors for resources listed in
+      the manifest fatal, while making it possible for other resources
+      to be removed from caches when they are removed from the server,
+      without errors, and making non-manifest resources survive
+      server-side errors.
 
      </li>
 
      <li><p>Otherwise, the fetching succeeded. Store the resource in
      the <var title="">new cache</var>.</p></li>
 
      <li><p>If the URL being processed was flagged as an "explicit
      entry" in <var title="">file list</var>, then categorize the
      entry as an <span title="concept-appcache-explicit">explicit
      entry</span>.</p></li>

|