W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2012

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

From: Josh Sharpe <josh.m.sharpe@gmail.com>
Date: Fri, 24 Aug 2012 00:12:22 -0400
Message-ID: <CAM2RUGNv=rqh85jO9nB=h0UTuduuM5hYzCxqzmB+kXuQTQ1oEA@mail.gmail.com>
To: whatwg@whatwg.org
Cross posted to help@whatwg.org two days, but forwarding here since I think
this might be a problem with the spec/implementation.

As it stands now, I think the only way I see out of this pinch is to make
my 404 and 500 error pages return 200 response codes.


---------- Forwarded message ----------
From: Josh Sharpe <josh.m.sharpe@gmail.com>
Date: Wed, Aug 22, 2012 at 11:06 AM
Subject: fallback section taking over for 4xx and 5xx responses while online
To: help@lists.whatwg.org

I have a manifest that looks something like this:

# e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a


/ /offline

Notably, it has a "/ /online" 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.

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.
 Since there is an error, and the url matches, the fallback section is
triggered, displaying the contents of /offline and not the response from
the given URL.

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.

While online, I would expect my 4xx and 5xx page to be rendered normally.

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.

Should I design this differently or is there something missing from the

Received on Friday, 24 August 2012 04:13:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:44 UTC