- From: Josh Sharpe <josh.m.sharpe@gmail.com>
- Date: Fri, 24 Aug 2012 00:12:22 -0400
- 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. Thanks! Josh ---------- 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: CACHE MANIFEST # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a /a/application.js /a/application.css NETWORK: * FALLBACK: / /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 spec? Thanks, Josh
Received on Friday, 24 August 2012 04:13:11 UTC