- From: David Barrett-Kahn <dbk@google.com>
- Date: Mon, 17 Dec 2012 16:27:29 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org, Josh Sharpe <josh.m.sharpe@gmail.com>
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@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
Received on Monday, 17 December 2012 22:28:01 UTC