[whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online

[David Barrett-Kahn]

Generally speaking, this feature is useful where the error page is somewhat
routine and contains information comprehensible and actionable by the user,
which would otherwise be lost in the fallback.

This was mainly about 404s, which docs will serve when a requested document
id doesn't exist, which includes cases where it was deleted.  All our
offline application could say (once triggered) was that the document was
not present in our local storage.  It couldn't say the document didn't
actually exist.  We therefore wanted the server's version of the error page
to be displayed.  401/403 were also of interest, mainly for cases where the
user had previously had access to a document, but that access had been
rescinded.  Whether it's a good idea to divert 500s kind of depends on what
they are, especially whether the served error page contains user-actionable
information.

The current generation of docs offline attempts to only engage the
browser's offline machinery when truly offline.  For example, the regular
docs pages one interacts with when online do not bind appcaches.  We have a
fallback entry covering the entire origin which engages this machinery,
loading a 'controller' style application which decides how to handle
whatever URL was provided.  We have this strict separation for two reasons.
 First, we were very keen to ensure that instability in the new offline
technologies we were using never lead to disruption of the online solution,
especially during early development.  Second, the online start-up
procedures used by our applications are complex and highly optimized, and
fundamentally incompatible with appcache due to a 'blending' of the
document and the application.  We wanted to preserve those optimizations
online and have a different startup procedure when offline.

-Dave


On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 11 Dec 2012, David Barrett-Kahn wrote:
> >
> > We ran into this same problem on Google Docs offline.  Our solution was
> > to add a proprietary response header to Chrome which instructs the
> > browser that the response is not to trigger the fallback entry, despite
> > its response code.  Something like it could be considered for
> > standardization. I know there are some people on the Chrome team looking
> > to advance some new appcache features, and that this use case is on
> > their list.
>
> Can you elaborate on the need for this feature? Why would you ever send
> the user to a 404 page intentionally (i.e. when the server isn't broken)?
> Similarly, why would you not consider the server returning 500 a good
> indication that the cache should be used?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
-Dave