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

[David Barrett-Kahn]

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.

For the time being, that header and the 'make everything a 200' solutions
are the only ones I know of.

https://bugs.webkit.org/show_bug.cgi?id=60493

-Dave


On Mon, Dec 10, 2012 at 1:37 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 24 Aug 2012, Josh Sharpe wrote:
> >
> > I have a manifest that looks something like this:
> >
> > CACHE MANIFEST
> > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a
> > /a/application.js
> > /a/application.css
> >
> > NETWORK:
> > *
> >
> > FALLBACK:
> > / /offline
> >
> > Notably, it has a "/ /offline" fallback section which is, obviously, a
> > prefix for every page on my site.  This is good, because the goal is to
> > have my users redirected to what's at /offline when they navigate to
> > www.mydomain.com while offline.
>
> Note that the Offline Application Cache feature is for Offline
> Applications, not Offline Sites. What you're trying to do here is not what
> appcache was designed to do.
>
> Also, it's not clear what you mean by "offline". For the record, in the
> spec, "offline" includes "I'm on wifi but there's a captive portal" and
> "I'm online but the server is broken".
>
>
> > As the fallback section is a prefix for everything, it's a prefix for any
> > url/path that results in an error condition such as a 404 or 500
> response.
>
> These are cases where it's assumed that the server is broken, i.e.
> offline, and the cache is therefore used.
>
>
> > It seems that the application cache, when it encounters an error state
> > such as a 404 or 500, doesn't check to see if the browser is still in
> > the 'online' state, and immediately falls over to the fallback section.
>
> It does check -- by definition, if it receives a 4xx or 5xx, it's assumed
> that the server is offline (broken).
>
>
> > While online, I would expect my 4xx and 5xx page to be rendered
> > normally.
>
> Offline Application Cache doesn't have a "while online" mode, it just
> always works as if you were offline and tries to get the data from the
> server while the server is able to respond.
>
> This is an important facet of how appcache works: it doesn't "work online"
> or "work offline". It always acts in "offline" mode (or rather, always
> works in "internet connection is flaky" mode).
>
>
> > Finally, the fallback section in my example is very typical of most
> > examples I find in various docs, including the whatwg spec.  I don't
> > think I'm doing anything abnormal here.
>
> What's abnormal is having the user visit pages that return 4xx or 5xx
> error codes when there's no problem. :-)
>
>
> > Should I design this differently or is there something missing from the
> > spec?
>
> It's hard to know exactly without understanding more about your use case.
> Can you elaborate on what you're trying to do?
>
>
> We could just exclude 4xx (and maybe 5xx? Though that seems less
> reasonable) error codes from being considered "offline" for fallback-
> supported resources, if people are commonly linking people to missing
> pages intentionally (and don't want the problem hidden from users by
> having it fall back to locally-generated pages). But that seems like a
> weird thing to do...
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
-Dave